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Deputy  Assistant  Secretary  of  the  Navy  (Safety)  Statement 


Our  men  and  women  in  uniform  are  putting  their  lives  on  the 
line  every  day  in  defense  of  our  freedoms  and  way  of  life.  Hence, 
we  all  have  an  inescapable  duty  and  responsibility  to  equip  them 
with  the  absolutely  best  capabilities  possible,  with  safety  as  a 
primary  and  enduring  factor.  System  safety  is  not  nice  to  have;  it  is 
an  integral  and  essential  part  of  the  systems  engineering  process. 
To  that  end,  the  Department  of  the  Navy  (DON)  is  focused  on 
integrating  system  safety  into  the  overall  acquisition,  systems 
engineering,  and  management  process — eliminating  hazards 
where  possible  and  making  sure  that  serious  and  high  risks  are 
brought  to  the  attention  of  the  leadership  that  can  provide  resources 
or  alter  operations  to  prevent  mishaps.  DON  manages  mishap 
risk  using  MIL-STD-882D,  Standard  Practice  for  System  Safety , 
to  identify,  analyze,  and  mitigate  hazards,  and  reconcile  residual 
risk.  Our  sustained  involvement  of  system  safety  in  acquisition 
programs  is  indispensable  toward  mitigating  hazards,  avoiding 
preventable  mishaps,  and  providing  sustained  affordable  readiness 
for  the  fleet.  System  safety  is  a  key  enabler  in  the  acquisition  and 
systems  engineering  process. 


LEADING 

EDGE 
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Introduction 


Naval  Surface  Warfare  Center,  Dahlgren  Division  (NSWCDD) 
Perspective  on  Systems  Safety  Engineering 


At  the  Naval  Surface  Warfare  Center  (NSWC)  Dahlgren,  we 
proudly  boast  that  we  have  in  some  way  touched  every  weapon 
system  deployed  by  the  U.S.  Navy,  as  well  as  many  deployed  by 
the  other  services.  One  of  the  most  important  contributions  we 
make  is  ensuring  that  these  systems  are  safe  in  the  hands  of  the 
warfighter.  Over  the  years,  we  have  tested  and  certified  thousands 
of  weapons  and  combat  systems  and  fully  comprehend  the  need 
to  integrate  safety  in  every  phase  of  development  from  design  to 
fielding. 

Our  systems  safety  engineers  are  second  to  none  and  have  es¬ 
tablished  processes  that  ensure  that  safety  is  an  integral  factor  in 
the  development  of  the  system.  Thanks  to  our  outstanding  leader¬ 
ship  and  the  dedication  of  our  systems  engineers  and  support  staff, 
we  are  now  able  to  avoid  mishaps  and  mitigate  risks  to  the  great¬ 
est  extent  possible. 

In  this  edition  of  the  Leading  Edge ,  you  will  have  an  opportu¬ 
nity  to  see  how  safety  standards  and  practices  have  evolved.  You 
will  get  an  inside  view  of  the  safety  review  boards,  whose  ultimate 
goal  is  to  ensure  that  the  weapons  and  weapon  control  systems 
that  the  Navy  and  Marine  Corps  field  are  safe  for  the  users.  You 
will  also  gain  a  better  understanding  of  the  board’s  role  in  evaluat¬ 
ing  weapon  systems  developed  by  other  services  and  ensuring  that 
they  are  also  safe  to  carry  and  operate  from  Navy  platforms. 

As  evidenced  in  many  of  the  examples  cited  in  this  Systems 
Safety  Engineering  issue  of  the  Leading  Edge ,  incorporation  of 
safety  requirements  and  allocation  of  resources  for  safety  analysis 
and  testing  early  allows  a  program  to  plan  and  execute  the  weap¬ 
on  system  safety  program  and  uncover  safety  issues  early,  when 
they  are  less  expensive,  and  solutions  are  easier  to  incorporate  into 
the  system  design.  Late  identification  of  safety  issues  not  only  can 
have  significant  impact  on  cost  and  schedule,  but  more  important¬ 
ly,  they  can  result  in  serious  safety  risks  for  individuals. 

This  Systems  Safety  Engineering  issue  of  the  Leading  Edge 
demonstrates  how  seriously  we  take  system  safety  at  NSWC  Dahl¬ 
gren.  Without  exception,  we  are  deeply  committed  to  ensuring 
that  the  systems  we  provide  are  safe  to  use  and  perform  consistent¬ 
ly  and  accurately  to  keep  our  men  and  women  in  uniform  out  of 
harms  way.  I  am  proud  to  stand  at  the  helm  of  a  Command  where, 
through  the  innovation  and  tireless  dedication  of  our  safety  engi¬ 
neering  teams,  we  are  making  such  a  significant  impact  on  todays 
warfare  systems  at  sea  and  combat  systems  in  theater. 
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Naval  Ordnance  Safety  and  Security  Activity  (NOSSA) 
Perspective  on  Systems  Safety  Engineering 


Laura  M.  DeSimone 
Executive  Director, 

Naval  Ordnance  Safety  and  Security  Activity 

Deputy  for  Weapons  Safety, 

Naval  Sea  Systems  Command 


The  ever-increasing  complexity  of  today’s  weapon  and  combat 
systems  present  unique  challenges  to  the  system  safety  communi¬ 
ty  As  weapon  system  complexity  increases,  so  does  the  potential 
for  a  minor  design  flaw  or  human  error  to  evolve  into  a  mishap. 
The  use  of  weapons,  especially  aboard  ships,  is  inherently  hazard¬ 
ous,  and  it  is  unlikely  that  all  hazards  can  be  prevented.  However, 
the  mishap  risk  associated  with  weapons  and  explosives  can  usu¬ 
ally  be  mitigated  to  an  acceptable  level.  It  is  therefore  imperative 
that  weapon  systems  be  systematically  analyzed,  using  the  most 
advanced  techniques  appropriate,  in  order  to  reduce  the  mishap 
risk  associated  with  hazards.  System  safety  is  the  process  of  “de¬ 
signing  in”  safety  by  “designing  out”  hazards  or  intentionally  re¬ 
ducing  the  probability  and  severity  of  hazards. 

The  Weapon  System  Explosives  Safety  Review  Board  (WSESRB) 
was  established  in  1967  following  two  destructive  and  deadly  ex¬ 
plosives  mishaps  aboard  U.S.  Navy  aircraft  carriers  USS  Oriskany 
and  USS  Forrestal.  The  WSESRB  is  chartered  by  the  Chief  of  Naval 
Operations  to  provide  independent  oversight  of  the  Department 
of  the  Navy  weapon  programs  safety  efforts.  From  the  very  onset 
of  the  WSESRB,  it  has  been  accepted  that  explosives  safety  over¬ 
sight  is  best  accomplished  by  ensuring  maximum  compliance  with 
longstanding  safety  requirements  through  the  life-cycle  develop¬ 
ment  of  each  weapon  system. 

WSESRB  reviews  provide  program  managers  an  objective,  in¬ 
dependent  assessment  of  their  safety  program.  The  system  safe¬ 
ty  program  ensures  identification  of  hazards  to  the  fullest  extent 
possible,  and  provides  for  the  introduction  of  protective  design 
measures  to  mitigate  the  hazards  early  in  the  system  development 
process.  The  ultimate  goal  of  a  WSESRB  review  still  stands  as  the 
Navy’s  focal  point  for  the  prevention  of  mishaps  involving  ammu¬ 
nition,  explosives,  and  related  systems,  thereby  eliminating  deaths, 
injuries,  lost  workdays,  and  property  and  environmental  damage. 
Mishap  prevention  costs  are  generally  less  than  the  mishap  costs; 
therefore,  a  robust  safety  system  program  reduces  the  total  expect¬ 
ed  system  costs. 

The  Department  of  Defense  has  adopted  system  safety  as  a  pri¬ 
mary  engineering  discipline,  within  systems  engineering,  stress¬ 
ing  preventive  measures.  The  results  of  a  thorough  and  rigorous 
system  safety  program  are  generally  not  visible,  because  the  sys¬ 
tem  safety  program  has  been  successful  in  preventing  mishaps, 
and  prevented  mishaps  are  not  a  quantifiable  metric.  Through  the 
collective  efforts  of  our  dedicated  system  safety  professionals,  the 
Navy  and  Marine  Corps  weapon  and  combat  system  developers 
deliver  safe,  effective,  and  affordable  systems  to  our  warfighters. 
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Engagement  Systems  Department  Perspective  on  Systems  Safety 


In  an  era  of  increasingly  irregular  warfare  and  sophisticat¬ 
ed  enemy  tactics,  it  is  more  important  than  ever  that  we  main¬ 
tain  a  technological  edge  in  the  engagement  systems  we  provide 
to  the  warfighters  who  defend  our  nations  freedom.  Integral  to 
that  premise  is  the  precept  that  those  engagement  systems  be  de¬ 
signed  to  fulfill  their  mission  as  reliably  and  efficiently  as  possi¬ 
ble.  Concurrent  with  that  premise  is  that  our  engagement  systems 
are  designed  and  fielded  such  that  they  maintain  the  highest  de¬ 
gree  of  safety  possible  for  the  people  who  use  them  in  the  conduct 
of  their  duties.  Meshing  these  two  objectives  sometimes  presents  a 
set  of  complex  obstacles.  It  is  often  the  paradox  of  modern  weap¬ 
on  systems  that  safety  and  reliability  are  at  odds.  The  highest  de¬ 
gree  of  one  may  preclude  the  highest  degree  of  the  other.  Therein 
lies  the  challenge  of  systems  safety  engineering,  and  we  at  the  Na¬ 
val  Surface  Warfare  Center  (NSWC)  are  meeting  that  challenge. 
Systems  safety  engineering  is  devoted  to  meeting  the  needs  of  our 
men  and  women  in  uniform  by  providing  them  with  weapon  sys¬ 
tems  that  are  safe  to  manufacture,  store,  transport,  field,  operate, 
and  maintain,  while  simultaneously  ensuring  that  they  maintain 
high  reliability  in  their  functionality.  From  Marine  Corps  infantry 
weapons  to  major  naval  combat  systems,  systems  safety  engineer¬ 
ing  strives  to  ensure  that  those  who  volunteer  to  risk  their  lives  in 
the  face  of  enemy  fire  on  behalf  of  this  nation  need  not  fear  any 
consequence  in  the  use  of  their  own  systems. 


Systems  Safety  Engineering  Division  Perspective  on  Systems  Safety  Engineering 


This  issue  of  the  Leading  Edge  showcases  systems  safety  engi¬ 
neering.  It  introduces  the  history  of  the  discipline,  explains  what 
system  safety  is,  the  roles  of  review  boards,  and  how  it  is  execut¬ 
ed.  While  a  significant  chain  of  policy  requirements  does  exist  for 
performing  system  safety,  the  real  justification  for  the  exercise  of 
safety  analysis  is  that  it  simply  makes  sense.  Ensuring  that  systems 
are  safe  helps  to  save  lives,  prevent  the  loss  of  costly  military  as¬ 
sets,  and  prevent  damage  to  the  environment.  In  this  issue,  you 
will  learn  about  the  numerous  ways  that  system  safety  is  support¬ 
ing  the  warfighter. 

The  system  safety  practitioner  is  a  unique  individual.  In  addi¬ 
tion  to  being  system  safety  experts,  they  must  be  educated  in  a  va¬ 
riety  of  scientific  and  engineering  disciplines,  as  well  as  maintain  a 
significant  level  of  proficiency  in  program  management.  Their  re¬ 
quired  level  of  overall  knowledge  about  the  system  that  they  sup¬ 
port  is  exceeded  by  very  few.  These  professionals  face  tremendous 
challenges  in  their  efforts  to  provide  innovative,  proactive,  and  re¬ 
liable  systems  safety  engineering  services.  Traditionally,  and  even 
more  so  in  the  current  wartime  environment,  they  are  often  faced 
with  conflicting  requirements,  insufficient  budgets,  and  the  stress 
of  compressed  timelines.  As  you  read  the  articles  in  this  issue,  I 
hope  you  will  gain  an  understanding  for  the  complexity  of  the  dis¬ 
cipline  and  an  appreciation  for  the  people  who  have  dedicated 
their  careers  to  ensuring  that  warfare  systems  have  been  subjected 
to  a  quality  system  safety  analysis. 

The  bottom  line  is  that  keeping  warfighters  safe  from  injury, 
safeguarding  the  environment,  and  protecting  equipment  is  what 
system  safety  is  all  about. 
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Systems  Safety  Engineering 


Defining  System  Safety 


System  Safety:  What,  Why, 
and  How  We  Got  There 


By  Clifton  A.  Ericson  II 
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Introduction 

To  some  degree,  the  endeavor  for  safety  has  always  been  around.  Humans  have  a  nat¬ 
ural  instinct  for  self  preservation  (i.e.,  safety),  although  some  individuals  seem  to  have  a 
higher  risk  tolerance  level  than  others.  Prior  to  the  advent  of  the  system  safety  method¬ 
ology,  safety  was  achieved  by  accident— people  did  the  best  job  they  could,  and  if  an  ac¬ 
cident  occurred,  they  merely  made  a  design  change  to  prevent  a  future  occurrence  and 
tried  again.  However,  as  systems  became  larger  and  more  techno -complex,  knowing 
how  to  make  a  system  safe  was  no  longer  a  simple  task.  And,  as  the  consequences  of  an 
accident  became  more  drastic  and  more  costly,  it  was  no  longer  feasible  to  allow  for  safe¬ 
ty  by  chance.  System  safety  was  a  natural  technological  advancement,  moving  from  the 
approach  of  haphazardly  recovering  from  unexpected  mishaps  to  deliberately  anticipat¬ 
ing  and  preventing  mishaps.  System  safety  is  a  design-for-safety  concept;  it  is  a  deliber¬ 
ate,  disciplined,  and  proactive  approach  for  intentionally  designing  and  building  safety 
into  a  system  from  the  very  start  of  the  system  design.  Overall,  the  objective  of  system 
safety  is  to  prevent  or  significantly  reduce  the  likelihood  of  potential  mishaps  in  order  to 
avoid  injuries,  deaths,  damage,  equipment  loss,  loss  of  trust,  and  lawsuits. 

System  safety  as  a  formal  discipline  was  originally  developed  and  promulgated  by 
the  military-industrial  complex  to  prevent  mishaps  that  were  costing  lives,  dollars,  and 
equipment  loss.  As  the  effectiveness  of  the  discipline  was  observed  by  other  industries, 
it  was  adopted  and  applied  to  other  industries  and  technology  fields,  such  as  commer¬ 
cial  aircraft,  nuclear  power,  chemical  processing,  rail  transportation,  medical,  and  agen¬ 
cies  such  as  the  Federal  Aviation  Administration  (FAA)  and  the  National  Aeronautics 
and  Space  Administration  (NASA). 

What  is  Safety? 

In  order  to  understand  system  safety ,  one  must  understand  the  related  terms  safe 
and  safety ,  which  are  closely  intertwined;  yet  each  term  has  different  nuances  such  that 
they  cannot  be  used  interchangeably.  In  addition,  the  terms  hazard ,  mishap ,  and  risk 
must  also  be  understood,  as  they  are  important  components  of  system  safety. 
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Safe  is  typically  defined  as  freedom  from  dan¬ 
ger  or  the  risk  of  harm,  secure  from  danger  or  loss. 
Safe  is  a  state  that  is  secure  from  the  possibility  of 
death,  injury,  or  loss.  A  person  is  considered  safe 
when  there  is  little  threat  of  harm.  A  system  is 
considered  safe  when  it  presents  low  mishap  risk 
(to  users,  bystanders,  environment,  etc.).  Safe  can 
be  regarded  as  a  state— a  state  of  low  mishap  risk 
(i.e.,  low  danger),  a  state  where  the  threat  of  harm 
or  danger  is  nonexistent  or  minimal. 

Safety  is  typically  defined  as  the  condition  of 
being  protected  against  physical  harm  or  loss.  Safe¬ 
ty  as  defined  in  MIL-STD-882D,  Standard  Practice 
for  System  Safety ,  is 

...freedom  from  those  conditions  that 
can  cause  death,  injury,  occupational  illness, 
damage  to  or  loss  of  equipment  or  property, 
or  damage  to  the  environment. 

Since  100%  freedom  is  not  possible,  safety  is 
effectively  “freedom  from  conditions  of  unaccept¬ 
able  mishap  risk.”  Safety  is  the  condition  of  being 
protected  against  physical  harm  or  loss  (i.e.,  mis¬ 
hap).  The  term  safety  is  often  used  in  various  ca¬ 
sual  ways,  which  can  sometimes  be  confusing.  For 
example,  “the  designers  are  working  on  aircraft 
safety”  implies  that  the  designers  are  establishing 
the  conditions  for  a  safe  state  in  the  aircraft  design. 


Another  example— “aircraft  safety  is  developing  a 
redundant  design”— implies  a  branch  of  safety  (i.e., 
aircraft  safety)  that  is  endeavoring  to  develop  safe 
system  conditions. 

It  should  be  noted  that  safety  itself  is  not  a  de¬ 
vice  (as  some  dictionaries  state);  its  a  state  of  being 
safe  or  an  activity  working  towards  creating  a  safe 
state.  A  safety  device  is  a  special  device  or  mecha¬ 
nism  used  to  create  safe  conditions  or  a  safe  design. 

The  definitions  for  the  terms  safe  and  safe¬ 
ty  hinge  around  the  terms  hazard ,  mishap ,  and 
risk ,  which  are  closely  entwined  together.  A  mis¬ 
hap  is  an  event  that  has  occurred  and  has  result¬ 
ed  in  an  outcome  with  undesired  consequences.  In 
system  safety,  the  terms  mishap  and  accident  are 
synonymous.  In  order  to  make  a  system  safe,  the 
potential  for  mishaps  must  be  reduced  or  eliminat¬ 
ed.  Risk  is  the  measure  of  a  potential  future  mishap 
event  expressed  in  terms  of  probability  and  conse¬ 
quence.  Safety  is  measured  by  mishap  risk,  which  is 
the  probability  of  the  potential  mishap  occurring, 
multiplied  by  the  potential  severity  of  the  losses  ex¬ 
pected  to  be  experienced  when  the  mishap  occurs. 
Hazards  are  the  precursor  to  mishaps,  and  thus  po¬ 
tential  mishaps  are  identified  and  evaluated  via 
hazard  identification  and  hazard  risk  assessment. 
Mishap  risk  provides  a  predictive  measure  that  sys¬ 
tem  safety  uses  to  rate  the  safety  significance  of  a 
hazard  and  the  amount  of  improvement  provided 
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by  hazard  mitigation.  In  summary  mishap  risk  is  a 
safety  metric  that  characterizes  the  level  of  danger 
presented  by  a  system  design  via  the  potential  mis¬ 
hap  risk  presented  by  system  hazards. 

What  is  System  Safety? 

System  safety  is  often  not  fully  appreciated 
for  the  contribution  it  can  provide  in  creating  safe 
systems  that  present  minimal  chance  of  deaths 
and  serious  injuries.  System  safety  invokes  and 
applies  a  disciplined,  formal,  and  planned  meth¬ 
odology  for  purposely  designing  safety  into  a  sys¬ 
tem.  A  system  can  be  made  safe  only  when  the 
system  safety  methodology  is  consistently  ap¬ 
plied  and  followed.  Safety  is  more  than  eliminat¬ 
ing  hardware  failure  modes;  it  involves  designing 
the  safe  system  interaction  of  hardware,  software, 
humans,  procedures,  and  the  environment,  under 
all  normal  and  adverse  failure  conditions.  Safe¬ 
ty  must  consider  the  entirety  of  the  problem,  not 
just  portions  of  the  problem;  i.e.,  a  systems  per¬ 
spective.  System  safety  anticipates  potential  prob¬ 
lems  and  either  eliminates  them  or  reduces  their 
risk  potential  through  the  use  of  design  safety 
mechanisms  applied  according  to  a  safety  order 
of  precedence. 

The  basic  interrelated  goals  of  system  safety  are 
to: 

•  Proactively  prevent  product/ system  accidents 
and  mishaps 

•  Protect  the  system  and  its  users,  the  public, 
and  the  environment  from  mishaps 

•  Identify  and  eliminate/control  hazards 

•  Design  and  develop  a  system  presenting  min¬ 
imal  mishap  risk 

•  Create  a  safe  system  by  intentionally  design¬ 
ing  safety  into  the  overall  system  fabric 

System  safety  is  a  process  for  conducting  the 
intentional  and  planned  application  of  manage¬ 
ment  and  engineering  principles,  criteria,  and  tech¬ 
niques  for  the  purpose  of  developing  a  safe  system. 
System  safety  applies  to  all  phases  of  the  system  life 
cycle.  The  basic  system  safety  process  involves  the 
following  elements: 

•  System  Safety  Program  Plan  (SSPP)  develop¬ 
ment 

•  Hazard  Identification 

•  Risk  Assessment 

•  Risk  Mitigation  and  Verification 

•  Risk  Acceptance 

•  Hazard  Tracking 

Since  many  systems  and  activities  involve 
hazard  sources  that  cannot  be  eliminated,  zero 
mishap  risk  is  often  not  possible.  Therefore,  the 
application  of  system  safety  becomes  a  necessity  in 


order  to  reduce  the  likelihood  of  mishaps,  there¬ 
by  avoiding  deaths,  injuries,  losses,  and  lawsuits. 
Safety  must  be  designed  intentionally  and  intel¬ 
ligently  into  the  system  design  or  system  fabric; 
it  cannot  be  left  to  chance  or  forced  in  after  the 
system  is  built.  If  the  hazards  in  a  system  are  not 
known,  understood,  and  controlled,  the  potential 
mishap  risk  may  be  unacceptable,  with  the  result 
being  the  occurrence  of  many  mishaps. 

Why  System  Safety? 

In  order  to  achieve  their  desired  objectives, 
systems  are  often  forced  to  utilize  hazardous 
sources  in  the  system  design,  such  as  gasoline,  nu¬ 
clear  material,  high  voltage,  or  high-pressure  flu¬ 
ids.  Hazard  sources  bring  with  them  the  potential 
for  many  different  types  of  hazards,  which  if  not 
properly  controlled,  can  result  in  mishaps.  In  one 
sense,  system  safety  is  a  specialized  trade-off  be¬ 
tween  utility  value  and  harm  value ,  where  utility 
value  refers  to  the  benefit  gained  from  using  a  haz¬ 
ard  source,  and  harm  value  refers  to  the  amount 
of  harm  or  number  of  mishaps  that  can  poten¬ 
tially  occur  from  using  the  hazard  source.  For  ex¬ 
ample,  the  explosives  in  a  missile  provide  a  utility 
value  of  destroying  an  intended  target;  however, 
the  same  explosives  also  provide  a  harm  value  in 
the  associated  risk  of  inadvertent  initiation  of  the 
explosives  and  the  harm  that  would  result.  Sys¬ 
tem  safety  is  the  process  for  balancing  utility  val¬ 
ue  and  harm  value  through  the  use  of  design  safety 
mechanisms.  This  process  is  often  referred  to  as 
designed-in  safety. 

Systems  have  become  a  necessity  for  modern 
living,  and  each  system  spawns  its  own  set  of  po¬ 
tential  mishap  risks.  Systems  have  a  trait  of  failing, 
malfunctioning  and/or  being  erroneously  operat¬ 
ed.  System  safety  engineering  is  the  discipline  and 
process  of  developing  systems  that  present  reason¬ 
able  and  acceptable  mishap  risk,  for  both  users  and 
nearby  nonparticipants.  System  safety  was  estab¬ 
lished  as  a  systems  approach  to  safety,  where  safe¬ 
ty  is  applied  to  an  entire  integrated  system  design, 
as  opposed  to  a  single  component.  System  safety 
takes  a  sum  of  the  parts  view  rather  than  an  indi¬ 
vidual  component  view. 

To  design  systems  that  work  correctly  and 
safely,  an  analyst  needs  to  understand  and  correct 
how  things  can  go  wrong.  It  is  often  not  possible 
to  completely  eliminate  potential  hazards  because 
a  hazardous  element  is  a  necessary  system  com¬ 
ponent  that  is  needed  for  the  desired  system  func¬ 
tions,  and  the  hazardous  element  is  what  spawns 
hazards.  Therefore,  system  safety  is  essential  for 
the  identification  and  mitigation  of  these  hazards. 
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System  safety  identifies  the  unique  interrelation¬ 
ship  of  events  leading  to  an  undesired  event  in  or¬ 
der  that  they  can  be  effectively  mitigated  through 
design  safety  features.  To  achieve  this  objective, 
system  safety  has  developed  a  specialized  set  of 
tools  to  recognize  hazards,  assess  potential  mishap 
risk,  control  hazards,  and  reduce  risk  to  an  accept¬ 
able  level. 

Mishaps  are  the  direct  result  of  hazards  that 
have  been  actuated.  Accidents  happen  because  sys¬ 
tems  contain  many  inherent  hazard  sources,  which 
cannot  be  eliminated  since  they  are  necessary  for 
the  objectives  of  the  system.  As  systems  increase 
in  complexity,  size,  and  technology,  the  inadver¬ 
tent  creation  of  system  hazards  is  a  natural  con¬ 
sequence.  Unless  these  hazards  are  controlled 
through  design  safety  mechanisms,  they  will  ulti¬ 
mately  result  in  mishaps. 

System  safety  is  an  intentional  process,  and 
when  safety  is  intentionally  designed  into  a  system, 
mishap  risk  is  significantly  reduced.  System  safe¬ 
ty  is  the  discipline  of  identifying  hazards,  assess¬ 
ing  potential  mishap  risk,  and  mitigating  the  risk 
presented  by  hazards  to  an  acceptable  level.  Risk 
mitigation  is  achieved  through  a  combination  of 
design  mechanisms,  design  features,  warning  de¬ 
vices,  safety  procedures,  and  safety  training. 


When  Should  System  Safety 
be  Used? 

Essentially,  every  organization  and  program 
should  always  perform  the  system  safety  process 
on  every  product  or  system.  This  is  to  make  the 
system  safe  and  also  to  prove  the  system  is  safe. 
Safety  cannot  be  achieved  by  chance.  This  concept 
makes  sense  on  large  safety- critical  systems,  but 
what  about  small  systems  that  seem  naturally  safe? 
Again,  a  system  should  be  proven  safe,  not  just  as¬ 
sumed  to  be  safe.  A  system  safety  program  can 
be  tailored  in  size,  cost,  and  effort  through  scal¬ 
ing,  based  on  standards,  common  sense,  and  risk- 
based  judgment. 

The  system  safety  process  should  particularly 
be  invoked  when  a  system  can  kill,  injure,  or  maim 
humans.  It  should  always  be  applied  as  good  busi¬ 
ness  practice,  because  the  cost  of  safety  can  easily 
be  cheaper  than  the  costs  of  not  doing  safety.  When 
system  safety  is  not  performed,  system  mishaps  of¬ 
ten  result,  and  these  mishaps  generate  associated 
costs  in  terms  of  deaths,  injuries,  system  damage, 
system  loss,  lawsuits,  and  loss  of  reputation. 

The  History  of  System  Safety 

From  the  beginning  of  mankind,  safety  seems 
to  have  been  an  inherent  human  genetic  element  or 
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force.  The  Babylonian  Code  of  Hammurabi  states 
that  if  a  house  falls  on  its  occupants  and  kills  them, 
then  the  builder  shall  be  put  to  death.  The  Bible  es¬ 
tablished  a  set  of  rules  for  eating  certain  foods,  pri¬ 
marily  because  these  foods  were  not  always  safe 
to  eat  given  the  sanitary  conditions  of  the  day.  In 
1943,  the  psychologist  Abraham  Maslow  proposed 
a  five-level  hierarchy  of  basic  human  needs,  and 
safety  was  number  two  on  this  list.  System  safety 
is  a  specialized  and  formalized  extension  of  our  in¬ 
herent  drive  for  safety. 

The  system  safety  concept  was  not  the  inven¬ 
tion  of  any  one  person,  but  rather  a  call  from  the 
engineering  community,  contractors,  and  the  mil¬ 
itary  to  design  and  build  safer  systems  and  equip¬ 
ment  by  applying  a  formal,  proactive  approach. 
This  new  safety  philosophy  involved  utilizing  safe¬ 
ty  engineering  technology  combined  with  lessons 
learned.  It  was  an  outgrowth  of  the  general  dissat¬ 
isfaction  with  the  fly-fix-fly,  or  safety  by  accident, 
approach  to  design  (i.e.,  fix  safety  problems  after  a 
mishap  has  occurred)  prevalent  at  that  time.  System 
safety  as  we  know  it  today  began  as  a  grass-roots 
movement  that  was  introduced  in  the  1940s,  gained 
momentum  during  the  1950s,  became  established 
in  the  1960s,  and  formalized  its  place  in  the  acquisi¬ 
tion  process  in  the  1970s. 


The  first  formal  presentation  of  system  safety 
appears  to  be  by  Amos  L.  Wood  at  the  Fourteenth 
Annual  Meeting  of  the  Institute  of  Aeronautical 
Sciences  (IAS)  in  New  York  in  January  1946.  In 
a  paper  titled  “The  Organization  of  an  Aircraft 
Manufacturers  Air  Safety  Program,”  Wood  em¬ 
phasized  such  new  and  revolutionary  concepts 
as: 

•  Continuous  focus  of  safety  in  design 

•  Advance  analysis  and  postaccident  analysis 

•  Safety  education 

•  Accident  preventive  design  to  minimize  per¬ 
sonnel  errors 

•  Statistical  control  of  postaccident  analysis 

Woods  paper  was  referenced  in  another  land¬ 
mark  safety  paper  by  William  I.  Stieglitz  titled  “En¬ 
gineering  for  Safety,”  presented  in  September  1946 
at  a  special  meeting  of  the  IAS  and  finally  print¬ 
ed  in  the  IAS  Aeronautical  Engineering  Review  in 
February  1948.  Mr.  Stieglitz s  farsighted  views  on 
system  safety  are  evidenced  by  the  following  quo¬ 
tations  from  his  paper: 

Safety  must  be  designed  and  built  into 
airplanes,  just  as  are  performance,  stability, 
and  structural  integrity.  A  safety  group  must 
be  just  as  important  a  part  of  a  manufacturer  s 
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System  Safety:  What,  Why, 
and  How  We  Got  There 


organization  as  a  stress,  aerodynamics,  or  a 
weights  group. . . 

Safety  is  a  specialized  subject  just  as  are 
aerodynamics  and  structures.  Every  engineer 
cannot  be  expected  to  be  thoroughly  famil¬ 
iar  with  all  developments  in  the  field  of  safety 
any  more  than  he  can  be  expected  to  be  an 
expert  aerodynamicist. 

The  evaluation  of  safety  work  in  posi¬ 
tive  terms  is  extremely  difficult.  When  an 
accident  does  not  occur,  it  is  impossible  to 
prove  that  some  particular  design  feature 
prevented  it. 

The  need  for  system  safety  was  motivated 
through  the  analysis  and  recommendations  re¬ 
sulting  from  different  accident  investigations.  For 
example,  on  22  May  1958,  the  Army  experienced 
a  major  accident  at  a  NIKE- AJAX  air  defense  site 
near  Middletown,  New  Jersey,  that  resulted  in  ex¬ 
tensive  property  damage  and  loss  of  lives  to  Army 
personnel.  The  accident  review  committee  rec¬ 
ommended  that  safety  controls  through  indepen¬ 
dent  reviews  and  a  balanced  technical  check  be 
established,  and  that  an  authoritative  safety  orga¬ 
nization  be  established  to  review  missile  weapon 
systems  design.  Based  on  these  recommendations, 
a  formal  system  safety  organization  was  estab¬ 
lished  at  Redstone  Arsenal,  Huntsville,  Alabama, 
in  July  1960,  and  AR  385-15,  System  Safety ,  was 
published  in  1963. 

The  Navy  experienced  explosives  mishaps  on 
USS  Oriskany  on  26  October  1966,  on  USS  Forrest- 
al  on  29  July  1967,  and  on  USS  Enterprise  on  15  Jan¬ 
uary  1969.  These  mishaps  caused  the  loss  of  many 
lives,  significant  ship  damage  and  aircraft  loss,  and 
came  close  to  sinking  these  aircraft  carriers.  These 
mishaps  motivated  new  safety  programs  and  con¬ 
cepts  for  Navy  weapon  systems  and  set  the  stage  for 
the  system  safety  process  (see  also  the  Navy  Safe¬ 
ty  Review  Board  article  authored  by  Caro,  Shamp- 
ine,  and  Waller  in  this  issue  of  The  Leading  Edge). 
Based  on  the  many  recorded  mishaps,  the  Secre¬ 
tary  of  Defense  (SECDEF)  created  the  Depart¬ 
ment  of  Defense  (DoD)  Explosives  Safety  Board 
(DDESB)  to  establish  a  basic  set  of  standards  and 
criteria  to  reduce  explosives  related  mishaps  and 
their  resulting  impact.  The  Chief  of  Naval  Oper¬ 
ations  (CNO)  established  the  Weapon  System  Ex¬ 
plosives  Safety  Review  Board  (WSESRB)  to  ensure 
that  required  explosive  safety  criteria  was  incorpo¬ 
rated  in  the  design  and  use  of  all  weapons  and/or 
explosive  systems. 

As  a  result  of  numerous  United  States  Air 
Force  (USAF)  aircraft  and  missile  mishaps,  the 


USAF  also  became  an  early  leader  in  the  develop¬ 
ment  of  system  safety.  In  1950,  the  USAF  Director¬ 
ate  of  Flight  Safety  Research  (DFSR)  was  formed 
at  Norton  Air  Force  Base  (AFB),  California.  It  was 
followed  by  the  establishment  of  safety  centers  for 
the  Navy  in  1955  and  for  the  Army  in  1957.  In 
1954,  the  DFSR  began  sponsoring  USAF-industry 
conferences  to  address  safety  issues  of  various  air¬ 
craft  subsystems  by  technical  and  safety  specialists. 
In  1958,  the  first  quantitative  system  safety  analy¬ 
sis  effort  was  undertaken  on  the  Dyna-Soar  X-20 
manned  space  glider. 

The  early  1960s  saw  many  new  developments 
in  system  safety.  In  July  1960,  a  system  safety  office 
was  established  at  the  USAF  Ballistic  Missile  Divi¬ 
sion  (BMD)  at  Inglewood,  California.  BMD  facil¬ 
itated  both  the  pace  and  direction  of  system  safety 
efforts  when,  in  April  1962,  it  published  the  first 
systemwide  safety  specification  BSD  Exhibit  62-41 
titled  System  Safety  Engineering:  Military  Specifica¬ 
tion  for  the  Development  of  Air  Force  Ballistic  Mis¬ 
siles.  The  Naval  Aviation  Safety  Center  was  among 
the  first  to  become  active  in  promoting  an  interser¬ 
vice  system  safety  specification  for  aircraft:  BSD 
Exhibit  62-82,  modeled  after  BSD  Exhibit  62-41.  In 
the  fall  of  1962,  the  Air  Force  Minuteman  Program 
Director,  in  another  system  safety  first,  identified 
system  safety  as  a  contract  deliverable  item  in  ac¬ 
cordance  with  BSD  Exhibit  62-82. 

The  first  formal  SSPP  for  an  active  acquisition 
program  was  developed  by  the  Boeing  Company 
in  December  of  1960  for  the  Minuteman  Program. 
The  first  military  specification  (Mil- Spec)  for  safe¬ 
ty  design  requirements— MIL-S-23069,  Safe¬ 
ty  Requirements,  Minimum,  Air  Launched  Guided 
Missiles — was  issued  by  the  Bureau  of  Naval  Weap¬ 
ons  on  31  October  1961. 

In  1963,  the  Aerospace  System  Safety  Society, 
which  later  became  the  current  System  Safety  Soci¬ 
ety,  was  founded  in  the  Los  Angeles  area.  In  1964, 
the  University  of  Southern  California’s  Aerospace 
Safety  Division  began  a  masters  degree  program 
in  Aerospace  Operations  Management  from  which 
specific  system  safety  graduate  courses  were  devel¬ 
oped.  In  1965,  the  University  of  Washington  and 
the  Boeing  Company  jointly  held  the  first  official 
System  Safety  Conference  in  Seattle,  Washington. 
By  this  time,  system  safety  had  become  fully  recog¬ 
nized  and  institutionalized. 

Presently,  the  primary  reference  for  system 
safety  is  MIL-STD-882,  which  was  developed  for 
DoD  systems.  It  evolved  from  BSD  Exhibit  62- 
41  and  MIL-S-38130,  Safety  Engineering  of  Sys¬ 
tems  and  Associated  Subsystems  and  Equipment, 
General  Requirements  for.  BSD  Exhibit  62-41 
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was  initially  published  in  April  1962  and  again  in 
October  1962;  it  first  introduced  the  basic  prin¬ 
ciples  of  safety  but  was  narrow  in  scope.  The  doc¬ 
ument  applied  only  to  ballistic  missile  systems, 
and  its  procedures  were  limited  to  the  concep¬ 
tual  and  development  phases  “from  initial  de¬ 
sign  to  and  including  installation  or  assembly  and 
checkout”  However,  for  the  most  part,  BSD  Ex¬ 
hibit  62-41  was  very  thorough;  it  defined  require¬ 
ments  for  systematic  analysis  and  classification 
of  hazards  and  the  design  safety  order  of  prece¬ 
dence  used  today  In  addition  to  engineering  re¬ 
quirements,  BSD  Exhibit  62-41  also  identified  the 
importance  of  management  techniques  to  control 
the  system  safety  effort.  The  use  of  a  system  safety 
engineering  plan  and  the  concept  that  manageri¬ 
al  and  technical  procedures  used  by  the  contractor 
were  subject  to  approval  by  the  procuring  author¬ 
ity  were  two  key  elements  in  defining  these  man¬ 
agement  techniques. 

In  September  1963,  the  USAF  released 
MIL-S-38130.  This  specification  broadened  the 
scope  of  the  system  safety  effort  to  include  “aero¬ 
nautical,  missile,  space,  and  electronic  systems.” 
This  increase  of  applicable  systems  and  the  con¬ 
cepts  growth  to  a  formal  Mil-Spec  were  important 
elements  in  the  growth  of  system  safety  during  this 
phase  of  evolution.  Additionally,  MIL-S-38130  re¬ 
fined  the  definitions  of  hazard  analysis.  These  re¬ 
finements  included  system  safety  analyses: 

•  System-integration  safety  analyses 

•  System  failure-mode  analyses 

•  Operational  safety  analyses 

These  analyses  resulted  in  the  same  classifica¬ 
tion  of  hazards,  but  the  procuring  activity  was  giv¬ 
en  specific  direction  to  address  catastrophic  and 
critical  hazards. 

In  June  1966,  MIL-S-38130  was  revised.  Re¬ 
vision  A  to  the  specification  once  again  expanded 
the  scope  of  the  system  safety  program  by  adding 
a  system  modernization  and  retrofit  phase  to  the 
life-cycle  phases  definition.  This  revision  further 
refined  the  objectives  of  a  system  safety  program  by 
introducing  the  concept  of  “maximum  safety  con¬ 
sistent  with  operational  requirements.”  On  the  en¬ 
gineering  side,  MIL-S-38130 A  also  added  another 
safety  analysis:  the  Gross  Hazard  Study,  which  is 
now  known  as  the  Preliminary  Hazard  Analysis. 
This  comprehensive,  qualitative  hazard  analysis 
was  an  attempt  to  focus  attention  on  hazards  and 
safety  requirements  early  in  the  concept  phase  and 
was  a  break  from  other  mathematical  precedence. 

But  changes  were  not  just  limited  to  intro¬ 
ducing  new  analyses;  the  scope  of  existing  analy¬ 
ses  was  expanded  as  well.  One  example  of  this  was 


the  operating  safety  analyses,  which  would  now 
include  system  transportation  and  logistics  sup¬ 
port  requirements  as  well.  The  engineering  chang¬ 
es  in  this  revision  were  not  the  only  significant 
changes.  Management  considerations  were  high¬ 
lighted  by  emphasizing  management’s  responsibil¬ 
ity  to  define  the  functional  relationships  and  lines 
of  authority  required  to  “assure  optimum  safety 
and  to  preclude  the  degradation  of  inherent  safety.” 
This  was  the  beginning  of  a  clear  focus  on  manage¬ 
ment  control  of  the  system  safety  program. 

MIL-S-38130 A  served  the  DoD  well,  allow¬ 
ing  the  Minuteman  program  to  continue  to  prove 
the  worth  of  the  system  safety  concept.  By  August 
1967,  a  triservice  review  of  MIL-S-38130 A  began 
to  propose  a  new  standard  that  would  clarify  and 
formalize  the  existing  specification,  as  well  as  pro¬ 
vide  additional  guidance  to  industry.  By  changing 
the  specification  to  a  standard,  there  would  be  in¬ 
creased  program  emphasis  and  accountability,  re¬ 
sulting  in  improved  industry  response  to  system 
safety  program  requirements.  Some  specific  objec¬ 
tives  of  this  rewrite  were  to  obtain  a  system  safe¬ 
ty  engineering  program  plan  early  in  the  contract 
definition  phase  and  maintain  a  comprehensive 
hazard  analysis  throughout  the  systems  life  cycle. 

MIL-STD-882  BECOMES  BEDROCK 
of  System  Safety  Procedures 

In  July  1969,  MIL-STD-882  was  published — 
System  Safety  Program  for  Systems  and  Associated 
Subsystems  and  Equipment:  Requirements  for.  This 
landmark  document  continued  the  emphasis  on 
management  and  expanded  the  scope  to  apply  to 
all  military  services  in  the  DoD.  The  full  life-cy¬ 
cle  approach  to  system  safety  was  also  introduced 
at  this  time.  The  expansion  in  scope  required  a  re¬ 
working  of  the  system  safety  requirements.  The  re¬ 
sult  was  a  phase-oriented  program  that  tied  safety 
program  requirements  to  the  various  phases  con¬ 
sistent  with  program  development.  This  approach 
to  program  requirements  was  a  marked  contrast 
to  earlier  guidance,  and  the  detail  provided  to 
the  contractor  was  greatly  expanded.  Since  MIL- 
STD-882  applied  to  both  large  and  small  pro¬ 
grams,  the  concept  of  tailoring  was  introduced, 
thus  allowing  the  procuring  authority  some  lati¬ 
tude  in  relieving  the  burden  of  the  increased  num¬ 
ber  and  scope  of  hazard  analyses.  Since  its  advent, 
MIL-STD-882  has  been  the  primary  reference 
document  for  system  safety. 

The  basic  version  of  MIL-STD-882  lasted 
until  June  1977,  when  MIL-STD-882 A  was  re¬ 
leased.  The  major  contribution  of  MIL-STD-882A 
centered  on  the  concept  of  risk  acceptance  as  a 
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criterion  for  system  safety  programs.  This  evolu¬ 
tion  required  introduction  of  hazard  probability 
and  established  categories  for  frequency  of  occur¬ 
rence  to  accommodate  the  long-standing  hazard 
severity  categories.  In  addition  to  these  engineer¬ 
ing  developments,  the  management  side  was  also 
affected.  The  responsibilities  of  the  managing  ac¬ 
tivity  became  more  specific  as  more  emphasis  was 
placed  on  contract  definition. 

In  March  1984,  MIL-STD-882B  was  pub¬ 
lished,  reflecting  a  major  reorganization  of  the  “A” 
version.  Again,  the  evolution  of  detailed  guidance 
in  both  engineering  and  management  require¬ 
ments  was  evident.  The  task  of  sorting  through 
these  requirements  was  becoming  complex,  and 
more  discussion  on  tailoring  and  risk  acceptance 
was  expanded.  More  emphasis  on  facilities  and  off- 
the-shelf  acquisition  was  added,  and  software  was 
addressed  in  some  detail  for  the  first  time.  The  ad¬ 
dition  of  Notice  1  to  MIL-STD-882B  in  July  1987 
expanded  software  tasks  and  the  scope  of  the  treat¬ 
ment  of  software  by  system  safety. 

With  the  publication  in  January  1993  of 
MIL-STD-882C,  hardware  and  software  were  in¬ 
tegrated  into  system  safety  efforts.  The  individual 
software  tasks  were  removed,  so  that  a  safety  anal¬ 
ysis  would  include  identifying  the  hardware  and 
software  tasks  together  in  a  system. 


The  mid-1990s  brought  the  DoD  acquisition  re¬ 
form  movement,  which  included  the  Military  Spec¬ 
ifications  and  Standards  Reform  (MSSR)  initiative. 
Under  acquisition  reform,  program  managers  are  to 
specify  system  performance  requirements  and  leave 
the  specific  design  details  up  to  the  contractor.  In 
addition,  the  use  of  Mil-Specs  and  standards  would 
be  kept  to  a  minimum.  Only  performance-orient¬ 
ed  military  documents  would  be  permitted.  Other 
documents— such  as  contractual  item  descriptions 
and  industry  standards— are  now  used  for  program 
details.  Because  of  its  importance,  MIL-STD-882 
was  allowed  to  continue  as  a  military  standard,  as 
long  as  it  was  converted  to  a  performance-orient¬ 
ed  military  standard  practice.  This  was  achieved  in 
MIL-STD-882D,  which  was  published  as  a  DoD 
Standard  Practice  in  February  2000. 

Although  system  safety  is  more  than  MIL- 
STD-882,  the  discipline  tended  to  grow  and  im¬ 
prove  with  each  improvement  in  MIL-STD-882. 
System  safety  is  now  a  process  that  is  formally 
recognized  internationally  and  that  is  used  to  de¬ 
velop  safe  systems  in  many  countries  throughout 
the  world. 

SUMMARY 

We  live  in  a  perilous  world  comprising  many 
different  hazards  that  present  the  risk  of  potential 
mishaps.  Hazards  and  risk  are  inevitable;  one 
cannot  live  life  without  exposure  to  hazards. 
However,  this  doesn’t  mean  that  mishaps  are 
inevitable.  We  also  live  in  a  world  composed  of 
technological  systems.  When  viewed  from  an 
engineering  perspective,  most  aspects  of  life 
involve  interfacing  with  systems  of  one  type  or 
another.  For  example,  consider  the  following  types 
of  systems  we  encounter  in  daily  life: 

•  Toasters 

•  Television  Sets 

•  Homes 

•  Electrical  Power 

•  Electrical  Power  Grid 

•  Hydroelectric  Power  Plant 

Commercial  aircraft  are  systems  that  oper¬ 
ate  within  a  larger  transportation  system  and  a 
worldwide  airspace  control  system.  The  automo¬ 
bile  is  a  system  that  interfaces  with  other  systems, 
such  as  other  vehicles,  fuel  filling  stations,  high¬ 
way  systems,  bridge  systems,  etc.  Everything  can 
be  viewed  as  a  system  at  some  level,  and  the  unique 
interconnectedness  and  complexity  of  each  system 
presents  special  challenges  for  safety.  Hazards  tend 
to  revolve  around  systems.  Safety  must  be  earned 
through  the  system  safety  process— it  cannot  be 
achieved  by  chance. 
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Determining  the  differences  between  opera¬ 
tional  and  safety  concerns  has  become  increasingly 
challenging  given  the  increased  complexity  of  sys¬ 
tems  being  developed  for  use  in  the  U.S.  Navy. 

Case  in  point:  new  ship  platforms  are  being  de¬ 
veloped  with  semiautonomous  antiterrorism/force 
protection  (AT/FP)  weapons  replacing  manned 
AT/FP  mounts.  The  increased  complexity  of  these 
systems— resulting  from  the  use  of  remote  and  cut¬ 
ting-edge  optics,  active  stabilization,  and  detect- 
control-engage  sequences  controlled  by  hardware/ 
software/firmware  combinations— creates  new  op¬ 
erational  and  safety  concerns  (see  Figure  1). 

Knowing  the  differences  between  the  two  is 
critical  in  conducting  accurate  mishap  risk  assess¬ 
ments  as  well  as  in  determining  operational  effec¬ 
tiveness.  The  following  article  presents  examples 
and  guidelines  associated  with  the  separation  of 
operational  and  safety  concerns  using  a  simple  case 
study  to  illustrate  the  challenges  faced  by  the  sys¬ 
tems  safety  engineer. 

The  challenge  of  delineating  between  an  oper¬ 
ational  concern  and  a  purely  safety  concern  is  that 
in  many  cases  the  two  disciplines  are  not  mutual¬ 
ly  exclusive.  In  reality,  there  are  many  overlapping 
issues,  and  the  only  absolute  certainty  is  that  per¬ 
sonnel,  equipment,  and  the  environment  must  be 
protected  to  the  maximum  extent  practicable  given 
the  nature  of  warfare,  mission  requirements,  and 
fiscal  constraints. 


The  increasing  complexity  and  autonomy  of 
naval  systems  has  resulted  in  an  approach  that  fo¬ 
cuses  not  just  on  the  design  of  a  system  but  also 
on  system  integration.  This  is  especially  true  when 
multiple  systems  are  being  assembled  into  an  over¬ 
arching  system  of  systems. 

This  system  integration  approach  has  been  ad¬ 
opted  by  the  system  safety  community  working 
in  the  Systems  Safety  Engineering  Division  at  the 
Naval  Surface  Warfare  Center,  Dahlgren  Division 
(NSWCDD).  The  Systems  Safety  Engineering  Divi¬ 
sion  is  tasked  with  performing  or  providing  govern¬ 
ment  oversight  for  contractors  performing  hazard 
analyses  in  accordance  with  MIL-STD-882D,  Stan¬ 
dard  Practice  for  System  Safety.  The  Platform  Sys¬ 
tem  Safety  Branch  focuses  on  the  design  and 
integration  of  ship  platforms  and  the  systems  that 
comprise  those  platforms.  Recent  analyses  that  fo¬ 
cus  on  the  integration  of  AT/FP  systems  have  dem¬ 
onstrated  the  increased  difficulty  of  discerning 
between  safety  and  operational  concerns. 

The  recent  implementation  of  the  Platform  Sys¬ 
tem  Safety  Approach  and  the  increased  complexi¬ 
ty  make  shipboard  AT/FP  systems  (see  Figure  2)  an 
ideal  case  study  to  help  develop  guidelines  for  the 
systems  safety  engineer  to  use  to  delineate  between 
purely  safety  and  operational  concerns,  as  well  as 
those  issues  that  have  both  safety  and  operational 
applicability.  Bottom  line— this  challenge  is  not  go¬ 
ing  away  anytime  soon. 


Figure  1.  Overlap  of  Safety  Concerns  and  Operational  Concerns 
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Figure  2.  Antiterrorism/Force  Protection  Weapons  Station  Aboard  T-AO  193 


It  is  important  to  remember  that  regardless  of  whether  issues  are  safety  or  operational, 
they  need  to  be  addressed  in  order  to  provide  the  warfighter  with  systems  that  are 
both  safe  to  use  and  operationally  effective. 


AT/FP  systems  are  generally  understood  as 
machine  guns  located  around  the  perimeter  of  a 
ship  platform  to  protect  from  asymmetric  threats. 
As  part  of  the  Platform  System  Safety  Approach, 
the  weapon,  mount,  and  ammunition— as  well  as 
the  operator— are  all  considered  part  of  the  AT/FP 
system. 

One  approach  that  can  be  used  to  separate 
safety  and  operational  concerns  is  to  create  a  set 
of  guidelines  or  “Rules  of  Engagement”  that  can 
be  used  to  categorize  each  issue  or  concern.  The 
following  list  of  guidelines  has  been  successful¬ 
ly  utilized  to  help  separate  safety  and  operational 
concerns  for  AT/FP  systems. 

•  If  the  concern  is  commonly  mitigated  by  a 
safety  device/interlock,  it  is  a  safety  concern. 

•  If  the  concern  involves  unintentional  firing 
of  weapons,  it  is  a  safety  concern. 

•  If  the  concern  involves  a  weapon  system  fir¬ 
ing,  and  it  hits  the  ship  in  which  it  was  fired 
from,  it  is  a  safety  concern. 

•  If  the  concern  involves  weapon  system  fail¬ 
ure/inability  to  engage  the  enemy,  resulting 
in  ownship  personnel  injury/death  or  ship/ 
equipment  damage,  it  is  not  a  safety  concern. 


•  If  the  concern  involves  weapon  system  un¬ 
successfully  engaging  the  enemy,  resulting 
in  ownship  personnel  injury/ death  or  ship/ 
equipment  damage,  it  is  not  a  safety  concern. 

•  If  the  concern  involves  the  misidentification 
of  a  target,  caused  by  the  target,  resulting  in 
the  target  being  fired  upon,  it  is  not  a  safe¬ 
ty  concern. 

•  If  the  concern  involves  the  misidentification 
of  a  target,  caused  by  the  firing  vessel,  result¬ 
ing  in  the  target  being  fired  upon,  it  is  a  safe¬ 
ty  concern. 

These  guidelines  are  further  defined  using  the 
following  descriptions  and  scenarios: 

If  the  concern  is  commonly  mitigated  by  a 
safety  device/interlock,  it  is  a  safety  concern.  It 
should  be  noted  that  safety  devices  can,  and  often 
do,  impact  operational  effectiveness.  It  is  the  re¬ 
sponsibility  of  the  systems  safety  engineer  to  main¬ 
tain  a  dialog  with  the  appropriate  design  team  to 
ensure  that  operational  effectiveness  is  minimally 
impacted  by  safety  devices.  For  example,  a  deck- 
mounted,  manually  operated  weapon  system  intro¬ 
duces  the  risk  of  the  gunner  falling  overboard,  an 
obvious  safety  concern.  The  installation  of  a  railing 


20 


Naval  Sea  Systems  Command 


Determining  the  Differences  Between 
Safety  and  Operational  Concerns 


is  safety  mitigation;  however,  the  railing  should  be 
installed  in  such  a  way  as  to  have  minimal  impact 
on  operational  effectiveness  of  the  weapon  system. 

If  the  concern  involves  unintentional  fir¬ 
ing  of  weapons,  it  is  a  safety  concern.  Safety  de¬ 
vices,  mechanical  and  software  interlocks,  safety 
procedures,  human  system  integration,  and  safe¬ 
ty  testing  all  serve  to  prevent  unintentional  fir¬ 
ing.  Safety  devices  and  procedures  that  are  meant 
to  prevent  unintentional  firing  must  be  balanced 
with  the  operational  requirement  for  those  weap¬ 
ons  to  by  fired  when  needed.  Not  balancing  these 
requirements  can  result  in  the  warfighter  purpose¬ 
ly  defeating  a  safety  device  in  order  to  increase  op¬ 
erational  effectiveness. 

If  the  concern  involves  a  weapon  system  fir¬ 
ing,  and  it  hits  the  ship  in  which  it  was  fired  from, 
it  is  a  safety  concern.  Mechanical  weapon  stops,  as 
well  as  pointing  and  firing  cutout  zones,  are  often 
employed  to  prevent  such  mishaps. 

If  the  concern  involves  weapon  system  fail¬ 
ure/inability  to  engage  the  enemy,  resulting  in 
ownship  personnel  injury/death  or  ship/equip¬ 
ment  damage,  it  is  not  a  safety  concern.  This  issue 
speaks  to  the  ability  of  a  system  to  accomplish  its 
mission.  While  the  overall  survivability  of  the  crew 
may  be  in  question  in  the  event  that  the  system  does 
not  engage  a  target,  this  is  an  operational  issue,  not 
a  safety  issue.  However,  it  must  be  understood  that 
system  safety  applies  during  combat  operations, 
and  the  system  safety  program  needs  to  address 
combat-specific  hazards  when  the  systems  design, 
operators,  or  interfaces  contribute  to  the  hazard. 

If  the  concern  involves  weapon  system  unsuc¬ 
cessfully  engaging  the  enemy,  resulting  in  own- 
ship  personnel  injury/death  or  ship/equipment 
damage,  it  is  not  a  safety  concern.  If  the  weapon 
system  engages  an  enemy  threat  and  misses  the  tar¬ 
get,  resulting  in  enemy- induced  damage,  it  is  not 
considered  a  systems  safety  engineering  concern,  as 
the  ownship  weapon  system  did  not  cause  the  dam¬ 
age— the  enemy’s  weapon  did.  This  situation  clear¬ 
ly  represents  a  significant  operational  performance 
and  survivability  concern,  but  it  is  not  an  issue  from 
the  systems  safety  engineering  perspective.  If  the 
systems  safety  engineer  were  to  adopt  these  perfor¬ 
mance  types  of  issues  as  safety  issues,  then  it  would 
significantly  water  down  the  effectiveness  of  the 
safety  program,  as  virtually  all  issues  would  become 
safety  issues. 

If  the  concern  involves  the  misidentification 
of  a  target,  caused  by  the  target,  resulting  in  the 
target  being  fired  upon,  it  is  not  a  safety  concern. 

An  example  would  be  a  civilian  craft  approaching 
a  U.S.  Navy  ship  in  such  a  manner  that  it  meets  the 


entire  criterion  for  the  use  of  deadly  force.  If  the 
approaching  craft  fails  to  respond  to  ownship  and 
is  engaged,  it  is  not  a  safety  concern  for  the  naval 
vessel.  While  the  naval  vessel  could  employ  less  le¬ 
thal  force,  the  decision  to  do  so  or  not  is  an  opera¬ 
tional  consideration  and  not  based  on  safety. 

If  the  concern  involves  the  misidentification 
of  a  target,  caused  by  the  firing  vessel,  result¬ 
ing  in  the  target  being  fired  upon,  it  is  a  safety 
concern.  An  example  would  be  if  a  future  remote 
weapon  system  used  an  image-recognition  pro¬ 
gram,  similar  to  facial  recognition,  to  detect  if 
the  passengers  on  a  small  boat  were  armed,  and 
a  software  error  resulted  in  identifying  the  boat  as 
hostile  when  it  was  not.  If  a  nonhostile  boat  were 
engaged  because  the  rules  of  engagement  were  not 
restrictive  enough,  that  would  be  an  operational 
and  safety  concern. 

These  guidelines  are  not  meant  to  be  all  inclu¬ 
sive  or  apply  to  all  systems  but  present  an  example 
from  which  system  safety  programs  can  develop 
more  enhanced  guidelines  for  their  specific  sys¬ 
tems.  Emerging  technology  in  naval  systems  has 
always  presented  new  and  unique  issues  that  con¬ 
tinually  challenge  systems  safety  engineers.  This 
boundary  will  need  to  be  revisited  and  redefined  as 
systems  become  even  more  complex  and  techno¬ 
logically  dependent. 
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The  Role  of  Environment,  Safety, 
and  Occupational  Health  (ESOH) 
in  the  System  Safety  Process 


Imagine,  if  you  will,  that  you  are  the  program 
manager  (PM)  for  a  large  military  acquisition  pro¬ 
gram  that  involves  multiple  components,  including 
an  armored  transport  vehicle  and  the  munitions 
that  it  will  fire.  This  particular  system  is  critical  to 
operations  in  theater,  and  your  program  team  is 
doing  everything  possible  to  get  the  system  field¬ 
ed  on  time,  or  early,  and  within  budget.  To  achieve 
this  goal,  your  acquisition  strategy  involves  using 
nondevelopmental  items  when  and  where  possi¬ 
ble,  resulting  in  the  pending  purchase  of  thousands 
of  penetrator  rounds  manufactured  outside  of  the 
United  States.  These  rounds  not  only  come  with  a 
proven  record  from  the  foreign  services  that  have 
used  them,  but  they  also  have  been  further  quali¬ 
fied  by  your  team  against  U.S.  standards. 

Everything  has  been  progressing  well  thus  far; 
until  one  day— during  the  course  of  a  routine  de¬ 
sign  meeting,  which  includes  the  involvement  of 
your  safety  and  environmental  personnel— an  is¬ 
sue  is  brought  up  that  keeps  you  up  at  night.  A 
member  of  the  safety  team  has  brought  to  your 
attention  that  your  penetrating  round  contains  a 
tungsten/nickel/cobalt  alloy,  a  material  that  has  re¬ 
ceived  widespread  Department  of  Defense  (DoD) 
attention  over  the  past  few  years  due  to  suspected 
carcinogenic  impacts  associated  with  its  use.  As  if 
that  isn’t  enough,  it  is  further  revealed  that  the  use 
of  tungsten  nylon  bullets  has  been  discontinued 
within  the  Army  due  to  suspected  leaching  into 
groundwater  and  subsequent  contamination  of  the 
area’s  groundwater. 

Supporting  details  related  to  both  these  is¬ 
sues— including  ongoing  studies,  DoD  actions, 
and  even  the  involvement  of  the  Environmental 
Protection  Agency  (EPA) — is  then  presented  to 
the  design  team.  In  the  midst  of  this  informational 
buzz,  you  realize  that  you  are  going  to  have  to  make 
some  difficult  decisions  that  are  likely  to  influence 
the  success  of  your  program,  not  just  in  terms  of 
mission  fulfillment,  but  also  in  terms  of  warfighter 
safety  and  environmental  health.  How  should  you 
proceed? 

Fortunately  for  you  and  for  all  acquisition  per¬ 
sonnel  in  similar  roles,  DoD  promotes  and,  in  ef¬ 
fect,  requires  the  integration  of  environment, 
safety,  and  occupational  health  (ESOH)  into  the 
systems  engineering  process.  This  article  will  at¬ 
tempt  to  define  ESOH,  explain  why  it  is  important, 
and  delineate  how  it  is  communicated  to  decision 
makers— all  within  the  context  of  the  DoD  acqui¬ 
sition  process.  In  doing  this,  some  insights  as  to  a 
path  forward  for  the  tungsten  scenario  presented 
above  will  be  revealed. 
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ESOH...WHAT  IS  IT? 

Within  DoD,  the  acronym  ESOH  is  used  to  de¬ 
scribe  the  three  separate,  but  related,  disciplines  of 
environment,  safety,  and  occupational  health  (OH) 
as  they  relate  to  risk  within  the  system  acquisition 
process.  The  following  paragraphs  provide  individ¬ 
ual  definitions  and  will  attempt  to  shed  some  light 
on  the  culture  that  may  have  influenced  the  prom¬ 
inence  of  these  disciplines  within  DoD. 

The  environmental  component  of  ESOH  deals 
with  environmental  issues  related  to  the  systems 
impact  upon  the  natural  environment  in  which 
people  live.  This  includes,  but  is  not  limited  to, 
such  things  as: 

•  Water,  soil,  and  air  pollution 

•  Harm  to  marine  mammals,  including  dol¬ 
phins  and  manatees 

•  Destruction  of  endangered  species  habitats, 
such  as  the  gray  wolf 

The  entire  life  cycle  must  be  assessed  when 
evaluating  environmental  risk,  including  manufac¬ 
turing,  testing,  fielding,  and  demilitarization  and 
disposal.  It  is  also  appropriate  to  consider  compli¬ 
ance  with  the  National  Environmental  Policy  Act 
(NEPA)  and  Executive  Order  (EO)  12114,  Envi¬ 
ronmental  Affects  Abroad  of  Major  Federal  Actions , 
when  assessing  environmental  ESOH  risk.  These 
two  elements  of  environmental  risk  are  so  highly 
regarded  within  DoD  that  they  are  called  out  sep¬ 
arately  within  Department  of  Defense  Instruction 
(DoDI)  5000.02,  Operation  of  the  Defense  Acquisi¬ 
tion  System ,  and  other  guiding  DoD  documents. 

Of  the  three  parts  of  ESOH  risk,  the  environ¬ 
mental  component  may  be  the  most  challenging 
to  evaluate  per  the  risk  assessment  methodolo¬ 
gies  employed  by  DoD  acquisition  safety  profes¬ 
sionals,  most  notably  those  found  within  Military 
Standard  (MIL-STD)-882D,  Standard  Practice  for 
System  Safety.  Often,  many  unknowns  surround 
long-term  fielding  of  a  military  system,  which 
make  assessment  of  potential  hazards  or  associated 
mishaps  difficult  during  the  initial  acquisition  pro¬ 
cess.  For  instance,  it  would  be  very  difficult  to  take 
into  account  the  progression  and  maturation  of  en¬ 
vironmental  research  and  regulations  that  would 
likely  occur  during  a  systems  lifetime,  Likewise,  it 
would  be  difficult  to  ascertain  the  many  locations  it 
may  function  in  around  the  world— all  character¬ 
ized  and  influenced  by  their  own  unique  set  of  re¬ 
quirements  and  sensitive  environmental  issues  and 
areas.  As  an  alternative  approach,  the  safety  pro¬ 
cess  would  serve  the  program  well  by  communi¬ 
cating  ESOH  risks  that  could  potentially  become 
programmatic  risks.  For  instance,  failure  of  a  pro¬ 
gram  to  even  address  NEPA  or  EO  12114  could 


negatively  impact  a  programs  performance,  sched¬ 
ule,  or  cost  and  should  be  communicated  to  the 
PM  as  part  of  the  system  safety  process. 

As  a  point  of  clarity,  a  good  definition  of  the 
term  environment  associated  with  ESOH  also  in¬ 
cludes  a  discussion  of  what  it  is  not  intended  to 
capture:  specifically,  the  impact  of  the  environ¬ 
ment,  both  natural  and  man-made,  upon  a  sys¬ 
tem.  In  other  words,  what  are  the  impacts  to  the 
system  caused  by  such  things  as  lightning  strikes, 
saltwater,  and  electromagnetic  interference?  Those 
impacts  are  instead  captured  in  other  parts  of  the 
systems  engineering  process  not  directly  related  to 
ESOH.  While  these  two  very  different  uses  of  the 
term  environment  do  enjoy  some  overlap  within 
the  acquisition  process— such  as  the  case  of  corro¬ 
sion,  which  can  simultaneously  impact  both  a  sys¬ 
tems  integrity  (via  oxidation)  and  the  health  of  the 
environment  (via  the  hazardous  components  used 
to  counteract  oxidation)—  they  are,  for  the  most 
part,  very  different  disciplines  and  should  be  treat¬ 
ed  as  such.  A  thorough  understanding  of  this  dis¬ 
tinction  will  serve  the  acquisition  professional  well 
in  understanding  ESOH  in  the  acquisition  process. 

In  terms  of  the  tungsten  example  previous¬ 
ly  discussed,  potential  environmental  ESOH  risks 
worthy  of  consideration  by  the  program  team 
mostly  include  those  upon  groundwater  and  soils 
due  to  possible  releases  from  materials  spent  on 
the  training  and  test  ranges.  The  PM  is  responsi¬ 
ble,  therefore,  for  assessing  this  environmental 
ESOH  risk  as  accurately  as  possible  and  to  com¬ 
municate  that  risk  to  all  decision  makers  involved 
in  the  program.  If  the  PM  and  the  team  determine 
that  significant  risk  exists,  and  if  the  acquisition 
program  is  still  in  the  early  stages,  it  may  be  feasi¬ 
ble  to  find  another  suitable  material  and  still  meet 
program  cost,  schedule,  and  performance.  In  cases 
where  the  program  is  further  down  in  the  acqui¬ 
sition  life  cycle  or  where  no  suitable  replacements 
exist  that  are  realistic,  then  the  ultimate  decision 
whether  to  proceed  as  planned  is  made,  taking 
into  account  the  ESOH  risk  and  the  mission  pri¬ 
ority.  If  the  program  moves  forward,  the  risk  must 
be  accepted. 

As  for  historical  influences  that  may  have 
shaped  DoD  s  own  interest  in  addressing  environ¬ 
mental  risks,  they  likely  parallel  a  general  tone  of 
environmental  responsibility  in  the  United  States 
beginning  in  the  late  1960s,  spurred  on  by  such 
events  as  Rachel  Carsons  1962  penning  of  the  con¬ 
troversial  Silent  Spring ,  the  passing  of  NEPA  in 
1969,  and  President  Nixons  establishment  of  the 
EPA  in  1970.  This  era  of  environmental  steward¬ 
ship  continued  as  this  country  watched  a  number 


24 


Naval  Sea  Systems  Command 


of  man-made  environmental  disasters  occur,  such 
as  the  Love  Canal  unveiling  in  1978  and  the  Three 
Mile  Island  incident  in  1979. 

The  safety  component  of  ESOH  deals  with  safe¬ 
ty  issues  associated  with  the  system.  Although  most 
emphasis  is  usually  placed  upon  identifying  safe¬ 
ty  ESOH  risks  associated  with  the  operation  of  the 
system— as  that  is  where  the  majority  of  hazards  are 
realized  into  mishaps — the  entire  life  cycle  should 
be  assessed,  to  include  manufacturing,  testing, 
maintenance,  storage,  handling,  and  demilitariza¬ 
tion  and  disposal.  Direct  assessment  of  the  manu¬ 
facturing  process  usually  falls  outside  the  scope  of 
the  acquisition  safety  professional,  as  these  risks  are 
normally  characterized  as  OH  and  are  addressed  by 
the  manufacturing  facility  through  corporate  safety 
and  health  policies  and  procedures.  Such  assuranc¬ 
es  for  a  safe  workplace  can  also  be  made  through 
contract  requirements.  Examples  of  risks  associat¬ 
ed  with  safety  are  inadvertent  explosion  (of  a  muni¬ 
tion),  pinch  points,  and  vehicle  rollover. 

Safety  ESOH  risk  lends  itself  very  well  to  the 
risk  assessment  methodologies  employed  by  the 
DoD  acquisition  safety  professional,  most  nota¬ 
bly  those  found  within  MIL-STD-882D.  Here,  one 
finds  solid  methodologies  for  assessing,  reporting, 
communicating,  and  accepting  safety  ESOH  risks 
within  the  acquisition  process. 

Again,  with  reference  to  the  tungsten  example, 
one  does  not  readily  find  any  direct  safety  ESOH 


risks;  however,  upon  closer  assessment,  the  impact 
of  a  friendly-fire  incident  (for  which  the  tungsten 
hazard  is  most  readily  realized  due  to  muscle-tis¬ 
sue  penetration)  would  certainly  be  considered  a 
safety  issue,  even  if  somewhat  indirect  in  nature. 
Although  there  may  also  be  ESOH  risks  associat¬ 
ed  with  manufacturing  or  demilitarization/dispos- 
al  of  the  tungsten  material  that  could  be  classified 
as  safety  risks,  they  might  better  be  captured  in  the 
OH  portion  of  ESOH. 

Regarding  historical  influences  upon  safety 
in  DoD,  one  sees  a  slow  evolution  of  safety  within 
20th-century  industrial  America  that  DoD  paral¬ 
leled,  whether  they  were  in  the  areas  of  automobile 
safety,  appliance  safety,  or  home  safety.  Addition¬ 
ally,  within  DoD  s  unique  history  reside  a  number 
of  tragic  events  that  were  instrumental  in  driving 
the  safety  train  within  defense  systems,  includ¬ 
ing — but  not  limited  to — the  Army’s  Nike  missile 
accident  in  1958  and  the  Navy’s  tragic  explosions 
aboard  USS  Oriskany  and  USS  Forrestal  in  1966 
and  1967,  respectively.  These  events  clearly  showed 
the  need  for  greater  safety  effort  within  all  of  DoD, 
so  a  prompt  response  was  elicited. 

The  OH  component  of  ESOH  also  deals  with 
safety  issues  of  the  system;  however,  it  tends  to 
address  those  risks  to  humans  associated  with  its 
manufacturing,  maintenance,  and  disposal,  as  well 
as  any  life-cycle  risks  associated  with  the  use  of 
hazardous  materials  (HAZMATs)  in  the  system. 
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Additionally,  OH  would  address  some  aspects  of 
human  systems  engineering  that  adversely  impact 
the  warfighter.  Examples  of  the  former  might  in¬ 
clude: 

•  Use  of  carcinogenic  solvents  during  manu¬ 
facturing 

•  Toxic  gas  and  noise  resulting  from  weapon 
firing 

•  Cadmium  exposure  associated  with  han¬ 
dling  of  corroded  equipment 

Examples  of  the  latter  might  also  include: 

•  Eyestrain  due  to  poor  video  displays 

•  Trip  hazards  due  to  poorly  designed  floor 
plates 

•  Low-hanging  light  fixtures  in  a  common 
passageway 

A  point  worth  noting  when  discussing  OH 
in  the  context  of  acquisition  is  the  frequent  direct 
overlap  between  safety  risks  and  OH  risks,  where¬ 
by  a  risk  may  be  classified  in  both  categories.  The 
important  thing  is  that  it  is  captured  in  one  of  the 
ESOH  assessments. 

Whereas  OH  ESOH  risks  can  and  should  be 
managed  via  MIL-STD-882  methodologies,  addi¬ 
tional  techniques  are  sometimes  necessary  and  en¬ 
couraged  to  communicate  these  risks  to  those  who 
might  benefit  the  most.  For  instance,  if  manufac¬ 
turing  a  particular  military  system  is  known  to  en¬ 
danger  a  plant  worker  s  health,  such  as  the  milling 
of  beryllium  materials,  the  safety  professional  may 
need  to  communicate  that  risk  directly  to  the  con¬ 
tractor  to  ensure  that  workers  are  being  adequate¬ 
ly  protected.  Alternatively,  if  the  material  has  been 
targeted  for  reduction  or  elimination  within  DoD, 
the  safety  professional  needs  to  ensure  that  other 
options  are  being  considered  by  the  program.  Al¬ 
though  the  MIL-STD-882  process  provides  for  this 
type  of  interchange,  the  timing  of  some  OH  risks  (in 
particular,  early  on  during  manufacturing)  is  differ¬ 
ent  from  that  of  typical  safety  risks  (such  as  those 
experienced  during  fielding),  thus  possibly  neces¬ 
sitating  additional  reporting  and  communication. 

In  terms  of  the  tungsten  example  previously 
discussed,  potential  OH  ESOH  risks  worth  assess¬ 
ing  would  include  those  associated  with  manufac¬ 
turing  the  metal  alloys.  Additionally,  consideration 
of  test-range  contamination  and  its  impact  on  hu¬ 
man  health  would  warrant  consideration  as  part  of 
OH  in  conjunction  with  environmental  impact. 

Some  basic  historical  research  reveals  an 
awareness  in  this  country  spanning  back  at  least 
into  the  early  20th  century,  when  child  labor  laws 
were  on  the  forefront  of  the  American  conscious. 
The  level  of  rigor,  however,  with  which  modern 
Occupational  Safety  and  Health  Administration 


(OSHA)  oversight  and  regulations  function  was 
not  fully  realized  until  the  past  few  decades,  as  sci¬ 
ence  and  research  started  producing  evidence  of 
afore-unnoted  health  hazards,  both  occupation¬ 
al  and  nonoccupational  (e.g.,  cigarette  smoking  is 
bad  for  ones  health;  asbestos  materials  shouldn’t  be 
inhaled;  exposure  to  leaded  gasoline  is  harmful  to 
developing  humans). 

ESOH... Why  is  it  important? 

Among  the  many  roles  and  responsibilities 
that  a  PM  faces  are  the  tasks  of  integrating  ESOH 
considerations  into  the  systems  engineering  pro¬ 
cess  and  managing  ESOH  risks  within  the  pro¬ 
gram.  These  requirements  are  identified  within 
DoDI  5000.02,  which  charges  the  PM  with  the  fol¬ 
lowing  responsibilities: 

•  The  PM  shall  integrate  ESOH  risk  manage¬ 
ment  into  the  overall  systems  engineering 
process  for  all  developmental  and  sustaining 
activities. 

•  The  PM  shall  eliminate  ESOH  hazards  where 
possible  and  manage  ESOH  risks  where  haz¬ 
ards  cannot  be  eliminated. 

•  The  PM  shall  ensure  that  appropriate  human 
systems  integration  and  ESOH  efforts  are  in¬ 
tegrated  across  disciplines  and  into  systems 
engineering. 

By  way  of  DoDI  5000.02,  DoD  also  endorses 
the  use  of  MIL-STD-882D,  which  provides  its  own 
level  of  instructions  and  definitions  germane  to  the 
role  of  the  PM  in  addressing  ESOH  issues  in  the  ac¬ 
quisition  process;  these  include: 

•  DoD  is  committed  to  protecting  private  and 
public  personnel  from  accidental  death,  in¬ 
jury,  or  occupational  illness. 

•  Within  mission  requirements,  DoD  will  also 
ensure  that  the  quality  of  the  environment  is 
protected  to  the  maximum  extent  practical. 

•  DoD  has  implemented  environmental,  safe¬ 
ty,  and  health  efforts  to  meet  these  objec¬ 
tives.  Integral  to  these  efforts  is  the  use  of  a 
system  safety  approach  to  manage  the  risk  of 
mishaps  associated  with  DoD  operations. 

This  standard  practice  addresses  an  approach 
(a  standard  practice  normally  identified  as  system 
safety)  useful  in  the  management  of  environmen¬ 
tal,  safety,  and  health  mishap  risks  encountered  in 
the  development,  test,  production,  use,  and  dis¬ 
posal  of  DoD  systems,  subsystems,  equipment, 
and  facilities. 

System  safety  is  the  application  of  engineer¬ 
ing  and  management  principles,  criteria,  and  tech¬ 
niques  to  achieve  acceptable  mishap  risk  within 
the  constraints  of  operational  effectiveness  and 
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suitability,  time,  and  cost,  throughout  all  phases  of 
the  system  life  cycle. 

A  mishap  is  an  unplanned  event  or  series  of 
events  resulting  in  death,  injury,  occupational  ill¬ 
ness,  damage  to  or  loss  of  equipment  or  property, 
or  damage  to  the  environment. 

Aside  from  complying  with  DoDIs  and  ac¬ 
cepted  safety  methodologies,  integrating  ESOH 
into  systems  engineering  just  makes  good  business 
sense.  Unaddressed,  ESOH  risks  can  readily  trans¬ 
late  into  programmatic  risks,  ultimately  costing  the 
program  in  terms  of  performance,  cost,  and  sched¬ 
ule.  Failure  to  address  environmental  concerns  can 
lead  to  poor  public  relations  and,  ultimately,  to  pro¬ 
gram  shutdown.  Failure  to  address  safety  concerns 
can  result  in  preventable  injuries  to  the  warfight¬ 
er,  and  failure  to  address  OH  issues  can  lead  to  a 
poorly  performing  and  unhealthy  workforce.  This 
list  could  go  on,  but  it  is  sufficient  to  say  that  early 
identification  and  management  of  all  ESOH  risks 
will  go  a  long  way  to  both  ensuring  compliance 
with  all  applicable  ESOH  laws  and  regulations,  and 
moving  toward  the  ultimate  success  of  the  acquisi¬ 
tion  program  and  safety  for  the  warfighter. 

As  a  final  note  regarding  the  PM  s  task  of  in¬ 
tegrating  ESOH  considerations  into  the  systems 
engineering  process,  it  is  useful  to  point  out  that 
safety  methodologies  and  instructions  provided 
by  DoD  and  industry  provide  some  latitude  for  its 
implementation  into  an  acquisition  program.  For 


instance,  some  safety  programs  focus  on  the  safe¬ 
ty  portion  of  ESOH  in  their  analyses  and  docu¬ 
mentation  and  rely  on  the  additional  support  of 
subject  matter  experts  in  the  area  of  environ¬ 
ment  and  OH  risks.  Other  programs  prefer  a 
more  comprehensive  approach,  whereby  the  safe¬ 
ty  professional  takes  ownership  of  the  entire  ESOH 
spectrum  in  their  analyses  and  documentation. 
It  is  also  important  to  realize  that  when  discuss¬ 
ing  ESOH  in  the  context  of  acquisition,  the  three 
components  of  ESOH  may  overlap.  For  instance, 
toxic  gas  could  be  regarded  as  an  environmental 
risk,  a  safety  risk,  and  an  OH  risk.  In  some  cases, 
it  may  be  adequate  to  capture  the  risk  under  only 
one  of  the  categories  (e.g.,  for  safety  and  OH,  ei¬ 
ther  one  may  suffice).  For  others,  it  may  be  neces¬ 
sary  to  call  them  out  under  both  categories  (e.g., 
for  hazards  impacting  both  the  environment  and 
the  human).  Regardless  of  the  safety  professionals 
approach,  the  important  thing  is  that  all  three  ele¬ 
ments  of  ESOH  are  sufficiently  considered  in  the 
system  safety  process. 

ESOH. ..HOW  IS  IT  COMMUNICATED? 

The  venue  that  connects  the  relationship 
among  the  environment,  safety,  and  OH  aspects  of 
ESOH  in  DoD  acquisition  programs  takes  the  form 
of  a  document  dubbed  the  Programmatic  Environ¬ 
ment,  Safety,  and  Occupational  Health  Evaluation, 
more  commonly  known  as  the  PESHE. 
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According  to  DoDI  5000.02,  the  PM,  regard¬ 
less  of  the  programs  Acquisition  Category  lev¬ 
el,  shall  prepare  a  PESHE  that  incorporates  the 
MIL-STD-882D  process.  This  document  includes: 

•  The  identification  of  ESOH  responsibilities 

•  The  strategy  for  integrating  ESOH  consider¬ 
ations  into  the  systems  engineering  process 

•  The  identification  of  ESOH  risks  and  their 
status 

•  A  description  of  the  method  for  tracking 
hazards  throughout  the  life  cycle  of  the  sys¬ 
tem 

The  composition  of  the  PESHE  is  finely  at¬ 
tuned  with  the  aforementioned  definition  of  sys¬ 
tem  safety.  The  PESHE  also  includes  identifying 
hazardous  materials,  wastes,  and  pollutants  (dis¬ 
charges/emissions/noise)  associated  with  the  sys¬ 
tem  and  planning  for  their  minimization  and/or 
safe  disposal  ,  as  well  as  a  compliance  schedule 
covering  all  system -related  activities  for  the  NEPA 
and  EO  14112. 

DoDI  5000.02  also  states  that  a  summary  of 
the  PESHE  shall  be  incorporated  in  the  Acquisition 
Strategy.  The  PESHE  is  not  only  a  required  docu¬ 
ment  per  DoD  and  the  Department  of  the  Navy 
(DON),  but  as  already  discussed,  elements  of  it  are 
also  required  by  statutory  requirements,  such  as 
NEPA  compliance,  which  is  mandated  in  sections 
4321-4370d  of  title  42  of  the  U.S.C.  These  require¬ 
ments  are  also  flowed  down  into  other  DON  and 
United  States  Marine  Corps  (USMC)  documents, 
such  as  Secretary  of  the  Navy  Instruction  (SEC- 
NAVINST)  5000. 2D,  Chief  of  Naval  Operations 
Instruction  5090. 1C,  and  Marine  Corps  Order 
P5090.2A— all  of  which  stipulate  the  development 
of  the  PESHE  in  DON  and  USMC  acquisition  pro¬ 
grams.  For  example,  SECNAVINST  5000.2D— an 
instruction  that  governs  the  implementation  and 
operation  of  the  defense  acquisition  system  and  the 
joint  capabilities  integration  and  development  sys¬ 
tem  for  DON  and  USMC  acquisition  programs— 
states  the  following: 

This  Acquisition  Strategy  shall  incorpo¬ 
rate  a  summary  of  the  Programmatic  ESOH 
Evaluation  (PESHE),  including  ESOH  haz¬ 
ards,  associated  risks,  and  proposed  mitiga¬ 
tion  plans;  a  strategy  for  integrating  ESOH 
considerations  in  the  systems  engineering 
process;  identification  of  ESOH  responsibili¬ 
ties;  a  method  for  tracking  progress;  and  a 
schedule  for  NEPA  (42  U.S.C.  sections  4321- 
4370d)  and  EO  12114  compliance  for  events 
or  proposed  actions  throughout  a  programs 
life  cycle. 


This  programmatic  document  is  a  tool  to  com¬ 
municate  to  decision  makers  how  ESOH  affects 
the  program.  For  all  programs,  the  PESHE  shall  be 
written  at  Milestonea  (MS)  B  and  updated  at  MS  C. 
The  PESHE  shall  be  updated  again  at  Full  Rate  Pro¬ 
duction/Deployment,  where  it  transitions  from 
an  initial  planning  document  to  an  ESOH  risk- 
management  tool.  For  ship  programs,  the  PESHE 
process  is  to  commence  even  earlier,  being  first  re¬ 
quired  at  MS  A. 

A  typical  PESHE  includes  sections  discussing 
programmatic  efforts  in  the  following  five  areas: 

1.  Environmental  Compliance — This  section 
describes  procedures  for  determining  envi¬ 
ronmental  compliance,  defines  compliance 
requirements,  and  analyzes  possible  im¬ 
pacts  of  compliance  on  the  programs  cost, 
schedule,  and  performance. 

2.  NEPA/EO  12114 — This  section  describes 
the  preparation  requirements  of  detailed 
statements  on  major  federal  actions  signif¬ 
icantly  affecting  the  quality  of  the  human 
environment  This  section  also  includes  a 
compliance  schedule  of  programmatic  ac¬ 
tivities  with  NEPA/EO  12114  and  planned 
NEPA  documentation  as  applicable. 

3.  System  Safety/OH— This  section  describes 
the  procedures  used  to  identify  and  elimi¬ 
nate  hazards;  defines  risk  levels;  and  sum¬ 
marizes  the  impact  of  potential  health  and 
safety  hazards,  including  loss  of  life,  person¬ 
nel  injury,  damage  to  environment,  or  dam¬ 
age  to  equipment. 

4.  Explosive  Safety— This  section  identifies 
explosives  ESOH  risks  and  mitigation  pro¬ 
cedures. 

5.  Hazardous  Material  (HAZM AT) /Pollu¬ 
tion  Prevention  (P2) — This  section  outlines 
the  goals  of  the  HAZMATs/waste  program 
and  related  issues,  and  includes  the  process 
for  identifying,  tracking,  handling,  and  dis¬ 
posing  of  HAZMATs  that  cannot  be  elimi¬ 
nated.  In  terms  of  P2,  this  section  describes 
programmatic  P2  initiatives  and  process¬ 
es  for  preventing  or  minimizing  impacts  on 
natural  resources. 

The  importance  of  the  PESHE  does  not  reside 
exclusively  in  the  fact  that  it  is  required  for  all  ac¬ 
quisition  programs.  More  importantly,  it  ensures 
awareness,  proper  planning,  and  compliance  of 
ESOH  issues  throughout  the  programs  life  cycle. 
This  versatile  document  also  serves  as  a  “snapshot” 
of  how  ESOH  issues  and  risks  are  being  managed. 
This  “snapshot”  describes  past,  present,  and  future 
programmatic  activities  related  to  ESOH,  and  in 
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that  sense,  the  PESHE  also  provides  a  history  of  all 
efforts  to  comply  with  ESOH  policies  and  regula¬ 
tions  while  minimizing  and  mitigating  associated 
risks.  On  the  other  hand,  the  PESHE  is  also  a  “self- 
correcting  exercise  ”  The  very  exercise  of  developing 
the  PESHE  may  reveal  flaws,  deficiencies,  or  needs 
of  the  program  that  can  be  corrected  or  anticipated 
before  final  signature  of  the  document.  For  exam¬ 
ple,  if  an  early  PESHE  version  reveals  the  presence 
of  a  HAZMAT  of  concern,  the  program  has  an  op¬ 
portunity  to  plan  by  avoiding  or  minimizing  the 
use  of  the  particular  HAZMAT.  Had  the  PESHE 
process  not  been  undertaken,  this  deficiency  may 
not  have  been  uncovered  until  a  key  programmatic 
review  such  as  a  Milestone  Decision  Authority  re¬ 
view,  where  the  chances  of  programmatic  risks  in¬ 
crease  and  can  be  translated  into  schedule  delays 
and  additional  costs  to  resolve  the  problem. 

The  PESHE  is  not  designed  to  supersede  oth¬ 
er  ESOH  plans,  analyses,  and  reports  (e.g.,  Sys¬ 
tem  Safety  Management  Plan,  P2  Plan,  and  Health 
Hazard  Assessment).  Instead,  the  PM  incorpo¬ 
rates  these  documents  by  reference,  as  appropriate. 
However,  to  the  maximum  extent  possible,  the  PM 
should  minimize  duplication  of  effort  and  docu¬ 
mentation  and  give  preference  to  recording  ESOH 
information  in  the  PESHE,  as  opposed  to  maintain¬ 
ing  a  series  of  overlapping,  redundant  documents. 
Ultimately,  the  PESHE  is  a  stand-alone  document 
that  contains  enough  material  to  inform  the  reader 
about  the  entire  programmatic  ESOH  effort. 

In  summary,  ESOH  describes  the  three  sepa¬ 
rate,  but  related  disciplines  of  environment,  safe¬ 
ty,  and  OH  as  they  relate  to  risk  within  the  system 
acquisition  process.  Its  importance  resides  main¬ 
ly  in  the  PM  s  responsibilities  of  integrating  ESOH 
into  the  systems  engineering  process  and  manag¬ 
ing  ESOH  risks  within  the  programs  life  cycle.  The 
venue  used  for  these  purposes  is  the  PESHE,  which 
serves  as  a  planning  document  in  the  early  stages 
of  the  program  and  evolves  to  a  risk-management 
tool  as  the  program  progresses.  The  ultimate  goal 
of  incorporating  ESOH  into  a  programs  life  cycle 
is  to  achieve  a  holistic  balance  between  minimiz¬ 
ing  risks  to  the  program,  the  environment,  and  the 
end  user  while  pursuing  the  delivery  of  equipment 
capable  of  accomplishing  its  mission. 

Endnote 

a.  The  point  at  which  a  recommendation  is  made  and  approval  sought 
regarding  starting  or  continuing  an  acquisition  program.  MSs  in 
acquisition  programs  are: 

A — Approves  entry  into  Technology  and  Development  Phase 
B — Approves  entry  into  the  Engineering  and  Manufacturing  Phase 
C— Approves  entry  into  Production  and  Deployment 
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By  James  H.  Yee,  Billie  Jo  Hynson,  and  Nga  Pham 


The  great  liability  of  the  engineer  compared  to  men  of  other  professions  is  that  his 
works  are  out  in  the  open  where  all  can  see  them.  His  acts ,  step  by  step ,  are  in  hard 
substance.  He  cannot  bury  his  mistakes  in  the  grave  like  the  doctors.  He  cannot  argue 
them  into  thin  air  or  blame  the  judge  like  the  lawyers.  He  cannot ,  like  the  architects , 
cover  his  failures  with  trees  and  vines.  He  cannot ,  like  the  politicians,  screen  his  short¬ 
comings  by  blaming  his  opponents  and  hope  the  people  will  forget.  The  engineer  simply 
cannot  deny  he  did  it.  If  his  works  do  not  work,  he  is  damned.— Herbert  Hoover 
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Herbert  Hoover  understood  well  the  weighty 
responsibility  and  accountability  that  has  bur¬ 
dened  the  engineer  since  the  beginning  of  time.  Al¬ 
though  man  may  boast  of  magnificent  engineering 
achievements,  his  pride  may  be  appropriately  tem¬ 
pered  by  many  more  failures  over  time.  Engineer¬ 
ing  history  is  replete  with  mistakes,  failures,  and 
mishaps.  We  need  look  no  further  than  the  Titan¬ 
ic ,  the  Tacoma  Narrows  Bridge,  and  the  space  shut¬ 
tle  Challenger  to  see  stark  examples  of  engineering 
shortcomings,  and  their  associated  consequences. 
Only  a  relative  few  have  been  immortalized  in  the 
annals  of  history  owing  to  their  tremendous  cost 
in  lives  and/or  resources.  Countless  more  have  es¬ 
caped  the  scrutiny  of  the  broader  public  eye  and 
the  indelible  ink  of  the  historian.  However,  each 
one  can  be  the  source  of  leading  indicators  and  les¬ 
sons  critical  to  the  understanding  and  prevention 
of  future  mishaps. 

Arguably,  the  greatest  tragedy  of  mistakes  oc¬ 
curs  if  we  don’t  learn  from  them.  Learning  from 
our  mistakes  affords  the  best  insurance  against  re¬ 
peating  history  or,  even  worse,  permitting  great¬ 
er  calamity.  As  much  as  learning  from  mistakes 
seems  to  be  an  elementary  concept,  for  one  reason 
or  another,  we  sometimes  fail  to  do  it.  Whether  at¬ 
tributable  to  expediency,  cost  cutting,  poor  com¬ 
munication,  or  just  plain  engineering  arrogance, 
the  result  is  the  same. .  .increased  risk. 

In  an  inherently  hazardous  environment,  such 
as  that  associated  with  military  operations,  the 
likelihood  of  mistakes  is  elevated,  and  the  conse¬ 
quences  are  increasingly  grave.  Given  this  fact,  it 
is  incumbent  upon  the  Navy  acquisition  commu¬ 
nity  to  ensure  that  the  systems  that  are  delivered  to 
our  Sailors  and  Marines  are  both  safe  and  effective. 
Safe  is  a  relative  term,  and  it  is  unrealistic  to  expect 
that  every  system  will  be  effective  and  safe  100% 
of  the  time.  Mistakes,  failures,  and  mishaps  have 
been,  and  unfortunately  probably  will  be,  a  part  of 
military  operations  until  the  end  of  warfare.  So  the 
challenge  to  the  acquisition  community  is  to  do 
everything  within  its  power  to  design  and  develop 
systems  that  are  as  safe  and  fault  tolerant  as  prac¬ 
ticable,  learn  and  incorporate  the  lessons  from  op¬ 
erational  use,  and  continuously  strive  to  avoid  the 
mistakes  of  the  past. 

Navy  Safety  Philosophy 
and  Mandate 

Safety  is  of  primary  importance  in  our  soci¬ 
ety  and  our  military.  Sending  our  nations  sons 
and  daughters  into  harms  way  is  difficult  enough 
without  having  to  worry  about  self-inflicted  inju¬ 
ries.  Recently,  the  Secretary  of  the  Navy,  Chief  of 


Naval  Operations,  and  Commandant  of  the  Ma¬ 
rine  Corps  signed  out  the  Department  of  the  Navy 
(DON)  Safety  Vision.  This  document  reinforc¬ 
es  past  policies  and  underscores  the  departments 
commitment  to  safety  by  reflecting  on  progress 
toward  achieving  safety  objectives  and  plotting  a 
course  for  the  future. 

Notably,  related  to  hazard  awareness  and  com¬ 
munication,  the  Safety  Vision  requires  Navy  com¬ 
mands  to: 

Aggressively  and  transparently  commu¬ 
nicate  safety  successes,  share  hazard  aware¬ 
ness  and  share  near-miss  lessons  learned. 

•  The  tenets  of  any  successful  safety  pro¬ 
gram  include  the  ability  to  rapidly  assess 
and  share  hazard  information  and  dis¬ 
seminate  lessons  learned.  Decisive  leader¬ 
ship  is  critical  in  creating  an  environment 
whereby  subordinate  commands  feel  em¬ 
powered  to  do  this  without  fear  of  adverse 
action.  Sharing  urgent  safety  information 
need  not  be  confined  to  established  and 
often  cumbersome  reporting  systems — or¬ 
ganizations  should  utilize  the  most  effec¬ 
tive  and  efficient  means  at  their  disposal.1 


This  requirement  is  part  of  the  Safety  Vision 
because  Navy  leadership  understands  that  effec¬ 
tive  information  sharing  is  a  critical  prerequisite  to 
effective  decision-making  and  subsequent  action. 
However,  the  fact  that  the  requirement  is  included 
as  part  of  the  course  for  the  future  implies  that  we 
are  not  there  yet. 

Arguably,  the  safety  culture  varies  between  the 
different  Navy  warfighting  communities  (e.g.,  air, 
surface,  subsurface,  special  operations).  The  level  of 
safety  risk  that  is  deemed  acceptable  varies,  as  well 
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as  the  propensity  and  willingness  to  share  safety- re¬ 
lated  information.  The  reasons  for  this  variance  are 
broad,  subject  to  opinion,  and  beyond  the  scope  of 
this  discussion.  Nonetheless,  the  mandate  from  the 
Safety  Vision  requires  the  culture  to  migrate  from 
wherever  it  is  right  now  to  a  point  where  there  is 
open  and  efficient  sharing  of  safety  information 
throughout  the  enterprise,  both  good  and  bad. 

Achieving  this  objective  will  afford  opportuni¬ 
ty  for  timelier  and  better  informed  safety  decision¬ 
making  across  all  stakeholders.  The  stakeholder 
community  ranges  from  the  individual  Sailor  to 
the  highest  echelon  commands.  Every  Sailor  and 
command  needs  to  play  a  proactive  role  in  the 
identification  and  mitigation  of  safety  hazards  pri¬ 
marily  because  hazards  can  reside  anywhere.  With¬ 
in  this  paradigm,  the  acquisition  community  can, 
and  must,  play  a  central  role. 

Acquisition  Community:  Uniquely 
Positioned  to  Influence  Safety 

The  ability  to  leverage  safety  information  from 
the  fleet  is  essential  to  the  end  objective  of  eliminat¬ 
ing  or  mitigating  mishap  risk.  In  November  2005, 
Deputy  Assistant  Secretary  of  the  Navy  for  Safety 
(DASN  (Safety))  issued  a  progress  report  on  the  Sec¬ 
retary  of  Defenses  (SECDEF  s)  challenge  of  50%  mis¬ 
hap  reduction.  Within  that  report,  DASN  (Safety) 
highlighted  a  new  challenge  in  the  FY06-1 1  Depart¬ 
ment  of  Defense  Strategic  Planning  Guidance  to  con¬ 
tinue  reducing  mishaps  and  mishap  rates  by  75%  by 
the  end  of  FY08,  using  FY02  statistics  as  a  baseline. 
The  principles  underlying  this  effort  are  threefold: 

1.  Mishaps  should  not  be  accepted  as  business 
as  usual 

2.  Most  mishaps  are  preventable 

3.  Mishap  prevention  leads  to  increased  read¬ 
iness 

In  June  2006,  the  SECDEF  issued  a  memoran¬ 
dum  on  reducing  preventable  mishaps.  The  tenets 
of  this  memorandum  have  since  been  reaffirmed 
by  the  current  Secretary.  In  this  memorandum, 
SECDEF  emphasized  accountability  at  all  levels 
with  regard  to  mishap  prevention.  He  also  states, 

If  we  need  to  change  our  training,  im¬ 
prove  our  material  acquisition,  or  alter  our 
business  practices  to  save  the  precious  lives 
of  our  men  and  women,  we  will  do  it.  We  will 
fund  as  a  first  priority  those  technologies  and 
devices  that  will  save  lives  and  equipment. 
We  will  retrofit  existing  systems,  and  consid¬ 
er  these  devices  as  a  “must  fund”  priority  for 
all  new  systems.  We  can  no  longer  consider 
safety  as  “nice  to  have.” 


Although  this  challenge  encompasses  all  facets 
of  Department  of  Defense  (DoD)  operations,  in¬ 
cluding  off-duty  and  ashore  mishaps  involving  mil¬ 
itary  personnel,  the  acquisition  community  has  a 
unique  opportunity  to  make  a  significant  contri¬ 
bution  toward  achieving  mishap  reduction  objec¬ 
tives,  thereby  improving  the  overall  safety  posture 
and  readiness  of  the  fleet. 

The  acquisition  community  is  in  the  best  posi¬ 
tion  to  eliminate  or  substantially  mitigate  hazards  as¬ 
sociated  with  systems  because  of  early  involvement 
in  concept  exploration  and  system  development. 
Factoring  safety  into  requirements,  design  deci¬ 
sions,  and  component  selections  is  the  most  cost-ef¬ 
fective  way  to  reduce  or  eliminate  mishap  risk. 

Figure  1  illustrates  the  relationships  among 
hazard  causal  factors,  hazards,  mishaps,  and  ef¬ 
fects.  The  following  is  an  example  of  each  element 
within  the  hierarchy: 

An  exposed  sharp  edge  in  a  relay  cabi¬ 
net  (hazard  causal  factor)  frays  the  insulation 
on  a  wire  (hazard)  leading  to  inadvertent  re¬ 
traction  of  missile  restraining  latches  and  a 
dropped  weapon  (mishap).  As  a  result,  the 
missile  suffers  stabilizer  damage  (effect). 

The  most  effective  approach  to  mishap  pre¬ 
vention  is  the  mitigation  or  elimination  of  haz¬ 
ards  that  may  potentially  lead  to  a  mishap.  Truly 
effective  elimination  and  substantial  mitigation  of 
hazards  is  most  achievable  during  the  system  de¬ 
velopment  process.  In  the  previous  example,  elim¬ 
ination  or  covering  of  the  sharp  edge  would  be  the 
most  effective  way  to  mitigate  the  hazards  caus¬ 
al  factor. 

What  is  commonly  referred  to  as  the  safe¬ 
ty  design  order  of  precedence  in  MIL-STD-882D 
(series),  Standard  Practice  for  System  Safety ,  lists 
“eliminating  hazards  through  design  selection”  as 
the  first  and  most  effective  method  for  ensuring 
safety.  Subsequent  mitigations,  in  order  of  prefer¬ 
ence,  include  incorporating  safety  devices,  provid¬ 
ing  warning  devices,  and  developing  procedures 
and  training. 

The  challenge  facing  the  acquisition  communi¬ 
ty  continues  to  grow  in  dimension  and  complexity. 
The  Maritime  Strategy  calls  for  an  unprecedented 
level  of  joint,  interagency,  and  coalition  integra¬ 
tion  and  interoperability  to  support  naval  opera¬ 
tions  comprising: 

•  Forward  Presence 

•  Deterrence 

•  Sea  Control 

•  Power  Projection 
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Results  In: 


Leads  To: 


Causes  A: 


Death,  injury,  illness, 
equipment  loss, 
equipment  damage, 
environmental  damage 


The  point  at  which  the 
inadvertent  release  of 
energy  occurred 


A  condition  that  exists 
within  the  system  that 
could  lead  to  a  TLMs 


Hazard  Causal 

Factors 

Human 


Subsystem 


IL 


Interface 


Element  within  the 
system  design, 

—  implementation,  or 
operation  that  leads 
to  a  hazard 


Figure  1.  Hazard  Relationships 


•  Maritime  Security 

•  Humanitarian  Assistance 

•  Disaster  Response 

Combined  with  a  push  toward  near- seamless 
interoperability,  this  mandate  multiplies  the  com¬ 
plexity  of  the  technical  challenges  facing  acquisition 
professionals.  Likewise,  there  is  a  commensurate 
increase  in  the  complexity  of  the  system  safety 
challenges. 

This  fact  alone  underscores  the  case  for  pro¬ 
viding  actionable  safety  hazard,  near-miss,  and 
mishap  information  to  the  acquisition  communi¬ 
ty.  The  increasing  complexity  of  our  systems,  not 
to  mention  the  value  of  our  people,  necessitates  an 
acquisition  process  in  which  learning  is  a  core  part 
of  the  culture.  The  consequences  of  failure  are  high, 
and  propagation  of  hazards  is  unacceptable. 

The  Value  of  Hazard  Awareness 

Lessons  learned  through  fleet  operations  and 
mishaps  provide  a  rich  source  of  information  that 
can  and  should  be  used  to  increase  awareness  and 
understanding  of  hazards.  The  fundamental  value 
of  such  information  is  multidimensional.  Primary 
benefits  include: 

•  Validating  or  invalidating  previously  incor¬ 
porated  hazard  mitigations— Mitigations  are 
normally  incorporated  into  the  system  de¬ 
sign  before  actual  fielding.  Sometimes,  due 


to  various  reasons,  what  was  thought  to  be 
an  adequate  mitigation  during  system  de¬ 
velopment  and  test  may  have  reduced  effec¬ 
tiveness  in  actual  employment.  Fleet  hazard/ 
mishap  information  will  provide  informa¬ 
tion  on  hazard  mitigation  effectiveness. 

•  Providing  insight  into  how  a  system  is  being 
used  in  the  fleet,  and  how  that  usage  diverges 
from  original  design  intent— Usage  outside 
of  the  original  concept  of  employment  may 
adversely  impact  the  safety  of  a  system.  Safe¬ 
ty  is  a  highly  contextual  facet  of  system  per¬ 
formance  that  is  in  large  part  reliant  upon 
use  of  a  system  as  designed,  in  the  antici¬ 
pated  environment,  by  an  operator  popula¬ 
tion  with  specific  skills.  A  stark  illustration 
of  this  point  taken  from  an  actual  mishap  is 
when  a  man  decided  to  use  a  lawn  mower  to 
trim  his  hedge.  This  type  of  unintended  uti¬ 
lization  of  a  lawn  mower  resulted  in  serious 
injury  due  to  the  bypassing  of  safety  mitiga¬ 
tions  and  the  introduction  of  new  and  un¬ 
foreseen  hazards. 

•  Providing  insight  into  significant  changes  in 
the  technical,  operational,  and/or  physical  as¬ 
pects  of  the  environment— Hazard  mitigations 
in  the  design  of  a  system  are  incorporat¬ 
ed  based  on  the  defined  concept  of  opera¬ 
tions  (CONOPS).  Given  the  ever-expanding 
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maritime  mission,  it  is  certainly  within  the 
realm  of  possibility  that  key  aspects  of  the 
environment  have  changed  enough  to  im¬ 
pact  safety.  Fleet  hazard/mishap  informa¬ 
tion  may  provide  critical  insight  into  these 
changing  factors. 

•  Highlighting  the  safety  qualities  of  various  de¬ 
sign  methods ,  materials ,  software ,  etc—  The 
rapid  infusion  of  new  systems  into  the  war¬ 
fare  environment  will  likely  shed  light  on  the 
safety  performance  of  associated  concepts, 
technologies,  and  materials.  Fleet  hazard/ 
mishap  information  may  provide  early  and 
valuable  input  to  current  and  future  design 
and  upgrade  decisions. 

•  Surfacing  new ;  unforeseen  hazard  condi¬ 
tions—  Despite  the  best  intentions  to  elim¬ 
inate  and  mitigate  all  hazards,  time  and 
money  are  seldom  sufficient  to  afford  the 
opportunity  to  do  so.  Operational  use  will 
likely  uncover  new,  unforeseen  hazards  that 
should  be  addressed  before  they  precipitate 
a  mishap.  Using  fleet  hazard/mishap  infor¬ 
mation,  the  acquisition  community  may  be 
able  to  detect  leading  indicators  of  unexpect¬ 
ed  safety  issues,  allowing  for  preemptive  ac¬ 
tion  and  incorporation  into  design  guidance. 


The  ability  to  leverage  actionable  safety  infor¬ 
mation  to  realize  these  benefits  is  crucial  to  im¬ 
proving  safety  throughout  the  fleet.  However,  in  a 
world  of  vast  and  competing  demands,  there  are  a 
number  of  significant  challenges  to  providing  ac¬ 
tionable  safety  hazard,  near-miss,  and  mishap  in¬ 
formation  to  the  acquisition  community. 

The  Current  Challenges 

The  primary  challenges  to  transitioning  ac¬ 
tionable  safety  information  from  the  fleet  to  the 
acquisition  community  are  threefold.  First,  there 
is  the  challenge  of  nurturing  the  requisite  atmo¬ 
sphere  in  which  the  reporting  of  safety  informa¬ 
tion  is  part  and  parcel  to  the  culture.  Second,  there 
is  the  challenge  of  defining,  developing,  and  imple¬ 
menting  the  processes  and  mechanisms  via  which 
the  information  may  be  communicated.  Finally, 
there  is  the  challenge  of  defining  the  specific  safety 
information  itself. 

A  positive  safety  culture  is  a  critical  aspect  to 
any  successful  safety-related  program.  The  culture 
must  be  geared  toward  open  and  timely  reporting 
without  fear  of  negative  consequences.  Tying  safe¬ 
ty  performance  to  rewards  and  recognition  can 
certainly  be  a  good  thing.  However,  an  unintend¬ 
ed  consequence  may  be  the  emergence  of  a  culture 
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that  discourages  reporting  of  hazards  and  near 
mishaps  that  do  not  exceed  the  mandatory  report¬ 
ing  threshold.  This  culture  would  emerge  if  report¬ 
ing  would  result  in  negative  impacts  to  things  such 
as  other  awards  and  promotion. 

Part  and  parcel  to  a  positive  reporting  culture 
is  the  implementation  of  processes  and  mech¬ 
anisms  for  reporting  that  are  readily  available, 
easy  to  understand,  and  user  friendly.  Reporting 
mechanisms  that  do  not  meet  these  requirements 
will  quickly  become  a  burden  to  Sailors  and  will 
likely  discourage  reporting.  The  design  and  im¬ 
plementation  of  reporting  mechanisms  need  to 
leverage,  to  the  greatest  extent  possible,  processes 
and  tools  that  are  already  institutionalized  in  the 
shipboard  environment,  taking  care  not  to  require 
duplicate  information. 

Last,  but  not  least,  the  best  safety  culture  com¬ 
bined  with  the  latest  processes  and  reporting 
mechanisms  are  all  for  naught  without  clear  data 
definition.  A  clear  and  widely  accepted  data  stan¬ 
dard  for  mishap,  near  miss,  and  hazard  reporting 
is  crucial  to  the  utility  of  the  data  by  the  acqui¬ 
sition  community.  Absent  data  standardization, 
the  potential  for  inaccurate  analyses  and  conclu¬ 
sions  is  high.  With  proper  data  standardization, 
the  acquisition  community  will  be  able  to  perform 


appropriate  analyses,  and  provide  reliable  and  val¬ 
ue-added  safety  recommendations  for  consider¬ 
ation  in  current  and  future  system  development 
efforts. 

These  challenges,  although  formidable,  are  not 
insurmountable.  There  are  collaborative  efforts 
within  the  Navy  safety  community  and  fleet  geared 
toward  addressing  all  these  challenges  and  coming 
up  with  viable  solutions  pursuant  to  the  DON  Safe¬ 
ty  Vision.  As  the  saying  goes, 

Nothing  worthwhile  comes  easily.  Half 
effort  does  not  produce  half  results.  It  pro¬ 
duces  no  results.  Work,  continuous  work, 
and  hard  work  is  the  only  way  to  accomplish 
results  that  last. 

A  key  ingredient  to  ultimate  success  in  safety 
is  continuing  to  focus  on  ways  to  improve  the  pro¬ 
cess.  With  support  from  senior  Navy  leadership, 
the  threats  posed  by  hazardous  environments  will 
be  mitigated,  and  the  fleet  will  be  safer. 

Reference 

1.  SECNAV  Memorandum  for  Distribution,  Subject:  DON  Safety  Vi¬ 
sion,  22  January  2009,  safetycenter.navy.mil/DON-Safety/ltr  Fi- 
nalVisionStatementwithexplanatorypara.pdf. 
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DoD  Acquisition  and  Technology  Programs 
Task  Force:  Promoting  System  Safety 
Throughout  the  Life  Cycle 


By  Elizabeth  Rodriguez- Johns  on  and  Mark  Geiger 


The  Department  of  Defense  (DoD)  Acquisition  and  Technology  Programs  Task 
Force  (ATP  TF)  seeks  to  put  action  behind  the  words,  “We  have  no  greater  responsi¬ 
bility  than  to  take  care  of  those  who  volunteer  to  serve”  The  DoD  set  goals  in  2003  and 
2006  to  reduce  prevent  able  accidents  by  50  percent  and  75  percent,  respectively  In  May 
2007,  the  Secretary  of  Defense  reiterated  the  Departments  target  as  “zero  preventable 
accidents,”  stating,  “We  can  no  longer  tolerate  the  injuries,  costs,  and  capability  losses 
from  preventable  accidents.” 

The  Defense  Safety  Oversight  Council  (DSOC)  was  established  in  2003  to  imple¬ 
ment  and  monitor  actions  designed  to  achieve  the  goal  of  reducing  preventable  ac¬ 
cidents.  The  DSOC  is  chaired  by  the  Under  Secretary  of  Defense  for  Personnel  and 
Readiness  (USD  (P&R)).  The  ATP  TF  is  one  of  nine  DSOC  task  forces  (see  Figure  1) 
and  is  chaired  by  the  Deputy  Director,  Human  Capital  and  Specialty  Engineering,  Of¬ 
fice  of  the  Deputy  Under  Secretary  of  Defense  for  Acquisition  and  Technology,  Systems 
and  Software  Engineering.  The  ATP  TF  promotes  improving  communication  between 
the  systems  engineering  and  system  safety  communities.  It  is  responsible  for  reviewing 
acquisition  policies  and  processes  and  for  studying  issues  concerning  safety  technolo¬ 
gy,  such  as  how  to  insert  safety  technology  into  existing  systems.  The  task  force  also  in¬ 
cludes  two  working  groups:  the  Aviation  Safety  Working  Group  and  the  Tactical  Vehicle 
Safety  Working  Group. 

ATP  TF  responsibilities  include  the  following: 

•  Ensure  that  acquisition  policies  and  procedures  address  safety  requirements 

•  Review  and  modify,  as  necessary,  relevant  DoD  standards  with  respect  to  safety 

•  Recommend  ways  to  ensure  acquisition  program  office  decisions  consider  sys¬ 
tem  hazards 

•  Recommend  ways  to  ensure  milestone  decision  reviews  and  interim  progress  re¬ 
views  address  safety 

The  ATP  TF  divides  its  initiatives  into  six  focus  areas  as  shown  in  Figure  2. 
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Figure  1 .  ATP  TF  Within  the  DSOC  Organization 


Figure  2.  ATP  TF  Focus  Areas 
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DoD  Policy  and  Guidance 

The  ATP  TF  focuses  on  safety  policy,  guidance, 
and  procedures  throughout  the  acquisition  life  cy¬ 
cle.  One  of  the  ATP  TF  s  major  accomplishments 
has  been  to  incorporate  safety  into  the  Department 
of  Defense  Instruction  (DoDI)  5000.02,  Operation 
of  the  Defense  Acquisition  System ,  dated  8  Decem¬ 
ber  2008.  As  the  foundation  for  processes  for  all 
DoD  acquisition  programs,  the  instruction  has  a 
huge  impact  on  how  programs  operate.  The  ATP 
TF  drafted  language  to  add  an  emphasis  on  safe¬ 
ty.  For  example,  the  language  calls  for  briefing  high 
and  serious  risks  using  the  MIL-STD-882D,  Stan¬ 
dard  Practice  for  System  Safety ,  methodology  at  ap¬ 
propriate  acquisition  program  reviews  and  fielding 
decisions.  It  also  requires  user  representatives  to  be 
a  part  of  the  risk  acceptance  process  throughout 
the  life  cycle  and  to  provide  formal  concurrence 
for  all  serious  and  high  risk  acceptance  decisions. 


ATP  TF  also  contributed  language  to  DoDI 
5000.02  to  address  mishap  reporting.  The  language 
calls  for  program  managers  to  support  system-re¬ 
lated  Class  A  and  Class  B  mishap  investigations 
by  providing  analyses  of  hazards  that  contributed 
to  the  mishap  and  recommendations  for  materiel 
risk-mitigation  measures,  especially  those  correc¬ 
tive  actions  that  minimize  human  errors. 

Figure  3  depicts  several  other  ESOH-related 
initiatives  the  ATP  TF  has  completed  and  is  un¬ 
dertaking  in  relation  to  the  DoDI  5000.02  and 
SECNAV  5000. 2D  acquisition  life  cycle. 

Joint  Safety  Certification 

The  ATP  TF  has  completed  several  guides,  in¬ 
cluding  the  Joint  Services  Weapons/Laser  Systems 
Safety  Review  (JSWLSSR)  Guide  to  Support  the 
U.S.  Special  Operations  Command  (USSOCOM). 
USSOCOM  approached  the  ATP  TF  with  concerns 
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•  Safety  Technologies 
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•  System  Safety-ESOH 
Evaluation  Tool 
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“V”  Model 

•  CLE  009 

•  23  DAU  Courses 
Updated 


*  DoDI  5000.02  and 
DAG  System 
Safety  Updates 

*  Software  Safety 
Guide  Updates 

*  ESOH  Risk 
Reporting  Guide 

*  MIL-STD-882D 
Update 


•  JCIDS  Process 

•  JCIDS  Guide 

•CJCSI  31 70.01  F  Update 

•  5  Assessment  Tools 

•  Joint  Safety  Test 
Requirements 

•  Guidance  on  Use 
of  CPLD 

•  Safety  Technology 
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Sustainment 

•  System  Safety-ESOH 
Evaluation  Tool 

•  CLE  009 

•  Unmanned  System 
Safety  Guide 

•  Systems  Engineering 
“V”  Model 

•  Safety  Technologies 
in  Tactical  Vehicles 


•  DoDI  6055.7 

•  2  Assessment  Tools 

•  ESOH  Risk  Reporting 
Guide 

•  MIL-STD-882D  Update 


Figure  3.  ATP  TF  Accomplishments  and  Initiatives  by  Life-Cycle  Phase 
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that,  because  of  a  lack  of  existing  policy,  joint  pro¬ 
grams  were  required  to  complete  multiple  safe¬ 
ty  certifications  through  the  different  services.  The 
process  was  repetitive  and  delayed  the  progress  of 
fielding  weapons. 

In  collaboration  with  weapon  safety  represen¬ 
tatives  from  USSOCOM,  the  Army,  Navy,  Marine 
Corps,  Air  Force,  and  the  Office  of  the  Under  Sec¬ 
retary  of  Defense  for  Acquisition,  Technology,  and 
Logistics,  the  ATP  TF  drafted  new  guidance  that 
streamlines  the  safety  certification  process.  This 
collaborative  review  process  accelerates  the  field¬ 
ing  of  weapon  systems  to  the  USSOCOM  warfight¬ 
er  without  compromising  safety.  The  response  has 
been  positive,  and  stakeholders  have  suggested  that 
all  joint  weapon  programs— not  just  USSOCOM 
programs— should  have  a  similar  process  out¬ 
lined  in  a  DoDI.  The  ATP  TF  is  currently  drafting 
the  Office  of  the  Secretary  of  Defense  (OSD)  Joint 
Weapon  and  Laser  System  Safety  Review  Guide 
and  a  proposed  DoDI,  and  is  coordinating  both 
documents  with  the  services. 

Safety  Practices  in  defense 
Acquisition  University  (DAU) 
Courses 

In  the  area  of  education,  the  ATP  TF  has  cham¬ 
pioned  incorporating  best  safety  practices  into 
DAU  systems  engineering  courses  and  has  created 
a  DAU  Continuous  Learning  Module  on  “System 
Safety  in  Systems  Engineering”  (CLE  009).  DAU 
courses  reach  all  members  of  the  acquisition  work¬ 
force  and  have  the  potential  to  make  a  significant 
impact  on  the  way  current  and  future  leaders  view 
safety  in  the  acquisition  process. 

More  than  4,000  students  have  taken  CLE  009. 
In  addition,  the  ATP  TF  has  sponsored  the  revi¬ 
sion  of  23  DAU  courses  to  incorporate  a  safety 


component.  The  ATP  TF  reviewed  all  appropri¬ 
ate  courses  in  detail  and  revised  them  to  include 
a  safety  element. 

For  example,  the  DAU  course  “Fundamen¬ 
tals  of  Systems  Engineering”  (SYS  101)  was  up¬ 
dated  as  part  of  the  ATP  TF  initiative  for  FY  2008. 
DoDI  5000.02  mandates  that  safety  be  addressed 
throughout  the  acquisition  process.  The  ATP  TF 
team  made  conservative  modifications  to  the  over¬ 
view  section  of  the  course  to  convey  that  the  dis¬ 
cipline  of  systems  engineering  plays  a  vital  role  in 
developing  not  only  effective  and  supportable  de¬ 
fense  systems,  but  also  safe  weapon  systems.  Ta¬ 
ble  1  shows  an  example  of  a  modified  paragraph. 

Periodically,  ATP  TF  subject-matter  experts  in 
the  appropriate  acquisition  and  environment,  safe¬ 
ty,  and  occupational  health  (ESOH)  disciplines  will 
continue  to  review  and  make  recommendations  for 
revision  to  the  DAU  courseware.  The  systems  en¬ 
gineering  courses  are  the  highest  priority  for  in¬ 
corporation  of  ESOH  content  because  the  DoD 
acquisition  process  requires  that  ESOH  hazard 
identification  and  risk  management  be  effectively 
integrated  into  the  systems  engineering  process  as 
a  design  consideration. 

Safety  Assessment  Tools 

Among  its  initiatives,  the  ATP  TF  has  spon¬ 
sored  several  research  studies,  resulting  in  assess¬ 
ment  tools  to  assist  programs  in  measuring  the 
effectiveness  of  their  designs  and  their  safety  pro¬ 
grams.  Examples  include: 

•  Noise  Exposure  Assessment  Tool  (NEAT) 

•  Evaluation  of  handrail  extension  devices  for 
shipboard  inclined  ladders 

•  Proactive  application  of  ergonomics  for  cost- 
benefit  analysis  in  design 

•  System  Safety  Metrics  Method 


Table  1.  Sample  DAU  Course  Modification 


Old  Wording  - 

DAU  SYS  101  Overview 


The  discipline  of  Systems  Engineering  plays  a  key 
role  in  helping  to  unify  the  technical  vision  of  a 
product;  to  effectively  manage  all  the  diverse  skills 
needed  to  develop  modern  defense  systems;  and 
to  help  ensure  that  effective,  supportable  systems 
get  fielded. 


New  Wording  - 

DAU  SYS  101  Overview 


The  discipline  of  Systems  Engineering  plays  a  key 
role  in  helping  to  unify  the  technical  vision  of  a  prod¬ 
uct;  to  effectively  manage  all  the  diverse  skills  need¬ 
ed  to  develop  modern  defense  systems;  and  to  help 
ensure  that  effective,  safe,  and  supportable  systems 
are  fielded. 
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•  Collaborative  project  with  the  Government 
Services  Agency  (GSA)  and  the  National  In¬ 
stitute  for  Occupational  Safety  and  Health 
(NIOSH)  to  have  low-vibration  power  hand 
tools  and  antivibration  gloves  made  available 
in  the  federal  supply  systems  to  prevent  the 
occurrence  of  hand- arm  vibration  syndromea 

Noise  Exposure  Assessment  Tool  (NEAT) 

The  effects  of  noise  exposure  have  often  been 
given  insufficient  attention  in  the  design  phase  be¬ 
cause  life-cycle  costs  and  human  effects  lack  the 
acute  and  immediately  quantifiable  impact  of  oth¬ 
er  categories  of  mishaps.  The  NEAT  project  used 
information  and  approaches  from  the  Navy  Un¬ 
dersea  Medical  Research  Institute  and  the  Center 
for  Naval  Analyses  to  develop  a  general  tool  for  as¬ 
sessing  the  life-cycle  cost  of  noise  exposures  with 
and  without  acoustic  control  measures.  Prior  re¬ 
search  validated  an  existing  relationship  between 
noise  exposures  and  hearing  loss  sustained  in  “in¬ 
dustrial”  workers  (ANSI  Standard  S3.44-1996) 
when  applied  to  a  Navy  population  with  more  pro¬ 
longed  exposures. 

Using  the  research,  the  project  developed  a 
well- documented  tool  for  broader  application  to  a 
range  of  systems  and  equipment.  The  tool  allows 
for  projection  of  the  cost  of  noise  exposures  from 
a  defense  system  (ship,  aircraft,  vehicle,  or  facili¬ 
ty)  and  provides  estimated  costs  of  compensation 
and  related  medical  effects  with  and  without  giv¬ 
en  levels  of  exposure  controls.  This  information 
provides  a  means  to  provide  cost-benefit  analysis 
for  implementation  of  noise  controls  (or  their  rel¬ 
ative  absence)  in  design.  An  ancillary  part  of  the 
tool  identifies  the  level  of  managerial  responsibil¬ 
ity  required  to  accept  the  level  of  risk  described  in 
accordance  with  defense  acquisition  regulations 
(DoDI  5000.02  application  of  MIL-STD-882D) 
and  speech/communication  impairment  associat¬ 
ed  with  noise  levels. 

Handrail  Extension  Devices  for  Shipboard  Inclined 
Ladders 

With  ATP  TF  sponsorship,  the  Naval  Surface 
Warfare  Center,  Carderock  Division  (Philadelphia 
Detachment),  is  spearheading  a  project  to  reduce 
injuries  associated  with  shipboard  inclined  lad¬ 
ders.  The  project  was  initiated  when  a  Naval  Safety 
Center  analysis  showed  that  approximately  50  per¬ 
cent  of  shipboard  falls  were  linked  to  descending 
inclined  ladders. 

Design  factors  were  evaluated  as  consistent 
with  the  ladder  angle  (not  readily  subject  to  retrofit) 
and  limitations  of  the  handrails.  In  locations  where 


the  hatch  must  be  able  to  close,  prohibiting  use  of 
a  typical  handrail,  current  designs  use  a  chain  and 
stanchion  to  provide  a  handrail  that  is  somewhat 
less  stable  than  a  fixed  one  and  subject  to  being  im¬ 
properly  rigged.  Researchers  are  evaluating  an  ex¬ 
tendable  handrail  as  an  alternative  (see  Figure  4). 
The  design  might  be  compared  to  a  trombone 
slide;  the  handrail  extends  and  can  be  locked  in 
place  temporarily,  then  retracted  to  allow  the  hatch 
to  close.  If  prototype  deployment  on  a  carrier  is 
successful,  PMS  278  (in-service  aircraft  carriers 
program)  anticipates  using  the  design  for  retrofit 
of  certain  shipboard  ladders. 

Ergonomics 

Ergonomic  interventions  have  frequently  im¬ 
proved  the  safety  and  efficiency  of  existing  op¬ 
erations  and  have  yielded  excellent  return  on 
investment  of  technology;  however,  it  has  been  dif¬ 
ficult  to  estimate  the  economic  and  human  impact 
of  ergonomics  and  human  systems  integration  ap¬ 
proaches  upon  new  systems  and  equipment.  How 
do  you  quantify  savings  from  a  mishap  that  did 
not  occur?  Furthermore,  how  does  a  design  engi¬ 
neer  with  limited  ergonomics  or  safety  background 
know  which  risk  factors  may  be  present  and  how  to 
evaluate  their  relative  hazards? 

An  ATP  TF-sponsored  project  described 
methods  for  identifying  ergonomic  risk  factors  in 
design,  provided  an  illustrated  guide  describing 
common  process  stressors/risk  factors,  and  devel¬ 
oped  a  detailed  guide  showing  risk  factors  at  each 
stage  of  the  system  life  cycle  for  common  defense 
systems.  The  associated  manual  and  report  dem¬ 
onstrate  approaches  to  the  evaluation  of  prospec¬ 
tive  risk  via  the  presence  of  known  ergonomic  risk 
factors.  Readily  understood  examples  are  used  to 
demonstrate  the  risk  reduction  and  manpower  sav¬ 
ings  associated  with  alternative  design  approaches. 
These  examples  can  be  used  to  justify  early  in¬ 
vestment  in  products,  such  as  materials  handling 
equipment,  on  the  basis  of  long-term  manpower 
savings  (a  critical  performance  parameter  for  ma¬ 
jor  acquisition  programs)  and  reduced  risk  to  op¬ 
erators  and  maintainers. 

Hand-Arm  Vibration  Syndrome 

Hand-arm  vibration  syndrome  is  an  irrevers¬ 
ible  syndrome  affecting  the  nerves  and  muscles  in 
the  fingers  and  hands  of  persons  with  intense  and 
prolonged  vibration  exposures  from  using  a  range 
of  vibrating  power  hand  tools.  It  has  been  report¬ 
ed  since  the  early  1900s.  Many  types  of  shipyard 
work  and  numerous  other  DoD  maintenance  op¬ 
erations  may  create  exposures  potentially  linked 
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Figure  4.  Handrail  Extension  for  Shipboard  Ladder 


to  development  of  this  syndrome.  The  key  to 
eliminating  this  preventable  disease  is  through  a 
combination  of  reduced  exposure  and  improved 
tools,  effective  protective  equipment,  work  prac¬ 
tice,  and  education. 

An  ATP  TF  project,  initiated  on  the  basis  of 
work  initially  performed  at  the  Puget  Sound  Naval 
Shipyard,  Washington,  has  engaged  the  NIOSH, 
the  GSA  office  managing  procurement  of  power 
hand  tools,  and  safety  and  health  representatives 
from  all  the  services.  The  working  group  has  de¬ 
veloped  procurement  criteria  for  power  hand  tools 
(considering  noise  and  vibration)  and  antivibra¬ 
tion  gloves,  and  guidance  for  third-party  product 
evaluation.  GSA  has  introduced  several  new  tools 
on  a  trial  basis,  and  groups  such  as  GSA,  NIOSH, 
and  the  DoD  Ergonomics  Working  Group  have  de¬ 
veloped  a  long-term  cooperative  arrangement. 

System  Safety  Metrics  Method 

The  System  Safety  Metrics  Method— released 
in  2009  and  now  available  for  programs— serves  as 
an  inexpensive,  useful  tool  to  gauge  the  health  of  a 
safety  program  at  any  stage  of  the  life  cycle.  Expe¬ 
rience  has  proven  that  a  strong  safety  program  re¬ 
sults  in  significant  savings  to  the  program,  reduced 
need  for  late  application  of  corrective  retrofits,  and 
often  more  effective  systems  at  lower  overall  cost. 

NAVSEA  Warfare  Centers 


The  ATP  TF  is  interested  in  receiving  feedback  on 
the  method,  which  may  be  downloaded  from  the 
ATP  TF  Web  site. 

Emphasizing  Safety  Early 
in  the  Life  Cycle 

As  depicted  by  the  blue  line  in  Figure  5,  the 
ATP  TF  is  continuing  to  focus  its  initiatives  on 
improving  safety  in  the  early  stages  of  the  acqui¬ 
sition  cycle,  because  the  cost  of  making  a  change 
to  a  system  later  in  the  development  cycle  is  nor¬ 
mally  prohibitive. 

The  red  line  in  Figure  5  shows,  notional- 
ly,  how  costs  increase  if  a  change  is  made  later  in 
the  development  cycle.  The  green  line  in  Figure  5 
depicts  how  system  safety  has  traditionally  been 
involved  in  the  acquisition  processes;  that  is,  in 
a  more  serial  manner  after  the  systems  and  de¬ 
sign  engineers  have  developed  conceptual  designs 
and  then  turned  those  designs  over  to  the  system 
safety  engineers  for  their  review  and  analysis. 
This  “serial  design  then  safety  review”  approach 
does  not  involve  the  system  safety  engineers  early 
enough  in  the  concept  design  process  to  eliminate 
potential  hazards.  Consequently,  the  ATP  TFs  fo¬ 
cus  is  to  establish  DoD  safety  policy  that  requires 
safety  to  be  addressed  increasingly  earlier  in  the 
acquisition  cycle. 
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For  example,  one  initiative  focuses  on  involv¬ 
ing  system  safety  and  ESOH  professionals  routinely 
in  the  drafting  and  review  of  Joint  Capabilities  and 
Integration  and  Development  System  (JCIDS)  doc¬ 
uments,  including  Initial  Capabilities  Documents, 
Capability  Development  Documents,  and  Capabil¬ 
ity  Production  Documents.  ESOH  subject-matter 
experts  may  be  able  to  provide  information  to  the 
JCIDS  that  has  the  potential  to  reduce  mishaps.  This 
initiative  and  associated  guidebook  will  support  the 
DoD  s  goal  of  reducing  risk  earlier  in  the  life  cycle. 

Through  coordinated  efforts,  the  ATP  TF  has 
accomplished  several  policy  and  guidance  im¬ 
provements  and  continues  to  pursue  new  safety 
initiatives.  The  ATP  TF  seeks  to  incorporate  safe¬ 
ty  considerations  early  in  the  life  cycle  to  have  the 
greatest  positive  impact  on  programs.  To  that  end, 
the  task  force  seeks  feedback  from  the  services  to 


ensure  that  it  is  implementing  policy  and  process 
changes  that  have  a  positive  impact  on  the  safety 
of  systems  provided  to  the  warfighter,  and  that  we 
are  not  overlooking  other  safety  needs  that  may 
be  visible  only  to  those  in  the  field.  Readers  are 
invited  to  consult  the  Web  site  and  send  feedback 
on  issues  that  stakeholders  believe  the  task  force 
should  address. 

Endnote 

a.  Hand- arm  vibration  syndrome  is  an  irreversible  neurovascu¬ 
lar  disease  affecting  the  fingers,  hands,  and  potentially,  upper 
arms.  It  is  associated  with  excessive  intense  and  prolonged  ex¬ 
posure  to  hand-arm  vibration,  typically  from  power  hand  tools. 
The  syndrome  is  underdiagnosed  but  has  been  documented  in 
the  United  States  since  the  early  1900s.  Many  operations  vital  to 
maintenance  of  defense  systems  and  facilities  have  the  poten¬ 
tial  to  create  significant  hand- arm  vibration  exposures.  Further 
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background  information  may  be  found  at  the  Naval  Safety  Cen¬ 
ters  Web  site,  http:// www.safetycenter.navy.mil/  acquisition/ 
vibration/ index,  asp 
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Navy  acquisition  programs,  particularly  weapon 
system  programs,  identify  a  Principal  for  Safety  (PFS)  to 
act  on  behalf  of  the  program  manager  (PM)  to  ensure 
that  the  systems  being  deployed  into  military  service  are 
safe.  The  role  of  the  PFS  is  complex  and  diverse  in  the 
duties  and  responsibilities  that  are  expected  of  these  in¬ 
dividuals.  The  myriad  of  standards,  guidebooks  and  pol¬ 
icies  providing  requirements  for  the  safety  program  can 
be  overwhelming.  However,  an  understanding  of  these 
policies  and  standards  is  essential  to  the  PFS  in  fulfilling 
their  responsibilities.  This  article  briefly  explores  those 
standards  and  offers  a  glimpse  at  the  impact  they  have  on 
the  PFS  in  the  conduct  of  the  safety  program. 

Principal  for  Safety  (PFS) 

The  PFS  is  the  “eyes  and  ears”  of  the  PM/manag- 
ing  authority  (MA)  in  regards  to  all  safety  matters  of  a 
system.  The  PFS  is  employed  to  ensure  that  the  best  in¬ 
terests  of  the  fleet  with  regard  to  safe  development,  op¬ 
eration,  maintenance,  and  disposal  of  a  system  is  taken 
into  consideration  when  making  acquisition  decisions. 
He  or  she  serves  at  the  pleasure  of  the  PM  and  should 
have  a  working  relationship  with  the  PM  and  any  pro¬ 
gram  office  representatives  designated.  It  is  the  job  of 
the  PFS  to  inform  the  PM  of  the  safety  risk  associated 
with  design  decisions  implemented  or  concepts  planned 
for  the  systems  under  their  purview.  The  PFS  must  be 
embedded  in  the  design  and  development  team(s),  yet 
stay  objective,  keeping  the  best  interests  of  the  user  in 
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mind.  It  is  very  easy  as  an  embedded  team  mem¬ 
ber  to  lose  objectivity  when  schedule  (would  us¬ 
ing  “budget”  work)  plays  such  an  important  role 
in  the  decision-making  process.  The  PFS  is  re¬ 
quired  to  have  a  wide  range  of  knowledge  regard¬ 
ing  all  aspects  of  the  system.  The  PFS  must  be  able 
to  rely  on  the  design  and  development  team  mem¬ 
bers,  as  well  as  subject  matter  experts  (SMEs),  to 
accomplish  the  mission  of  fielding  as  safe  a  system 
as  possible  within  technological  and  programmat¬ 
ic  constraints.  Facilitating  this  interaction  while 
maintaining  independence  and  objectivity  is  the 
challenge  faced  by  the  PFS. 

IT’S  THE  Law 

We  all  want  what  is  best  for  our  warfight¬ 
ers.  We  especially  want  to  ensure  that  we  provide 
our  troops  with  the  safest  equipment  and  systems 
possible.  This  idea  is  important  enough  that  the 
U.S.  government,  via  the  U.S.  Congress,  passed 
legislation  to  institutionalize  the  concept  into  law. 
The  Department  of  Defense  (DoD)  is  required,  by 
law,  to  establish  and  maintain  an  explosives  safety 
program.  U.S.  Code  Title  10,  Section  172  provides 
this  mandate.  It  instructs  the  military  to  establish 
joint  boards  to  oversee  preventing  hazardous  con¬ 
ditions  from  arising  that  may  endanger  life  and 
property.  Since  its  enactment  into  law,  the  con¬ 
cept  of  a  system  safety  program  and  the  respon¬ 
sibilities  therein  have  been  further  delineated  by 
DoD  and  the  Navy  through  a  multitude  of  direc¬ 
tives  and  instructions,  each  of  which  defines  in 
some  measure  how  the  PFS  performs  the  duties 
of  the  role. 

Directives 

Department  of  Defense  Directive  (DoDD)  5000.1 

DoDD  5000.1,  The  Defense  Acquisition  System , 
of  12  May  2003,  provides  a  specific  section  on  safe¬ 
ty.  Enclosure  1.23, “Safety,”  states  that: 

Safety  shall  be  addressed  throughout  the 
acquisition  process.  Safety  considerations 
include  human  (includes  human/system  in¬ 
terfaces),  toxic/hazardous  materials  and  sub¬ 
stances,  production/manufacturing,  testing, 
facilities,  logistical  support,  weapons,  and 
munitions/explosives.  All  systems  containing 
energetics  shall  comply  with  insensitive  mu¬ 
nitions  criteria. 

Whether  the  systems  that  we  work  on  are 
weapons  or  explosives  related,  they  are  all  re¬ 
quired  to  address  safety.  As  the  point  person  for 


safety,  the  PFS  is  responsible  for  guiding  the  sys¬ 
tem  safety  program  in  the  development  and  im¬ 
plementation  of  a  System  Safety  Program  Plan 
that  will  address  all  aspects  of  the  system  life  cy¬ 
cle  and,  thereby,  all  aspects  of  the  acquisition 
process. 

Department  of  Defense  Instruction  (DoDI)  5000.02 

DoDI  5000.02,  Operation  of  the  Defense  Ac¬ 
quisition  System ,  of  8  December  2008,  was  recent¬ 
ly  updated  and  has  numerous  references  to  safety. 

The  acceptance  of  risk  by  the  appropriate  au¬ 
thority  is  one  section  of  this  instruction.  After  all 
design  and  procedural  mitigations  have  been  iden¬ 
tified,  employed,  and  documented  for  the  safe¬ 
ty  program,  the  residual  safety  risk  in  the  system 
must  be  accepted  by  the  appropriate  authority.  The 
PFS  is  responsible  for  ensuring  that  residual  sys¬ 
tem  safety  risk  has  been  identified  and  quantified 
in  terms  of  hazards,  which  could  potentially  result 
in  mishaps,  and  for  further  ensuring  that  the  extent 
of  that  risk  is  clearly  communicated  to  the  level  of 
authority  charged  with  accepting  the  risk  or  with 
deciding  that  it  is  not  acceptable. 

INSTRUCTIONS 

Secretary  of  the  Navy  Instruction  (SECNAVINST) 
5000.2C 

SECNAVINST  5000. 2C,  Implementation  and 
Operation  of  the  Defense  Acquisition  System  and 
the  Joint  Capabilities  Integration  and  Develop¬ 
ment  System ,  dated  19  November  2004,  provides 
direction  for  program  acquisition  and  joint  ca¬ 
pabilities  integration  development  strategies. 
There  are  many  areas  in  this  instruction  that  ad¬ 
dress  safety. 

For  the  PFS,  the  SECNAVINST  5000.2C  re¬ 
quirements  should  be  documented  as  part  of  a 
programs  formal  acquisition  strategy.  When  a  PFS 
joins  a  program,  depending  on  the  life  cycle  or  de¬ 
velopment  phase  the  program  is  in,  the  PFS  should 
investigate  what  were  the  submission  documenta¬ 
tion  for  these  strategies  and  review  to  ensure  that 
the  program  is  in  compliance  with  the  require¬ 
ments  of  this  instruction. 

SECNAVINST  51 00. 1  OH 

SECNAVINST  5100.10H,  Department  of  the 
Navy  Policy  for  Safety ;  Mishap  Prevention ,  Occupa¬ 
tional  Health,  and  Fire  Protection  Programs ,  dated 
15  June  1999,  directs  the  Chief  of  Naval  Opera¬ 
tions/Commandant  Marine  Corps  (CNO/CMC) 
to  establish  safety  programs.  The  entire  instruction 
should  be  read  and  understood  by  the  PFS. 
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Office  of  the  Chief  of  Naval  Operations  Instruction 

(OPNAVINST)  5100.19D 

OPNAVINST  5100. 19D,  Navy  Occupational 
Safety  and  Health  (NAVOSH)  Program  Manual  for 
Forces  Afloat,  dated  5  October  2000,  documents  the 
overall  administrative,  organizational,  and  training 
aspects  of  the  NAVOSH  program,  including  poli¬ 
cy  and  responsibilities.  The  purpose  is  to  provide 
commanding  officers,  safety  officers,  managers,  su¬ 
pervisors,  and  workers  for  afloat  commands  with 
the  guidance  and  direction  necessary  to  implement 
the  NAVOSH  Program. 

A  PFS  engaged  in  conducting  safety  analysis 
of  a  system  designed  for  shipboard  use  may  gain 
a  wealth  of  knowledge  regarding  the  safe  conduct 
of  afloat  operations  by  reading  and  understanding 
this  instruction.  Of  particular  interest  is  Volume  II, 
Section  C,  “Surface  Ship  Safety  Standards.”  Insight 
into  how  business  is  conducted  afloat  is  very  ben¬ 
eficial  to  the  PFS,  especially  for  one  who  does  not 
have  direct  military  operational  experience. 

OPNAVINST  5100.24B 

OPNAVINST  5100.24B,  Navy  System  Safety 
Program  Policy ,  dated  6  February  2007,  is  the  pol¬ 
icy  that  guides  implementation  of  system  safety  in 
the  Navy.  It  discusses  the  background,  applicabil¬ 
ity,  and  Navy  System  Safety  Policy  specifically.  It 
also  clearly  defines  the  responsibilities  of  the  dif¬ 
ferent  entities  involved  in  military  operations.  The 
instruction  discusses  implementation  of  safety 
programs  and  provides  details  to  guide  the  reader. 


This  instruction  will  help  the  PFS  understand 
the  policy  and  direction  on  who  has  authority  over, 
and  responsibility  for,  the  safety  programs  under 
their  purview.  It  will  help  guide  them  in  a  general 
understanding  of  Navy  system  safety  and  the  doc¬ 
umented  requirements  for  the  programs. 

OPNAVINST  8000. 16C 

OPNAVINST  8000. 16C,  Naval  Ordnance  Main¬ 
tenance  Management  Program  ( NOMMP %  dated 
1  September  2006,  is  issued  to  define  responsibil¬ 
ities,  policies,  and  procedures  for  conducting  the 
Naval  Ordnance  Maintenance  Management  Pro¬ 
gram  at  all  levels. 

The  PFS  that  assesses  ordnance  handling  and 
topside  design  configurations  will  be  most  interest¬ 
ed  in  this  instruction.  It  offers  details  as  to  when  and 
what  type  of  ordnance  program  reviews  and  inspec¬ 
tions  are  required,  as  well  as  the  government  organi¬ 
zations  performing  those  reviews  and  inspections. 

OPNAVINST  8020.14 

OPNAVINST  8020.14/MCO  P8020.ll,  DON 
Explosives  Safety  Policy  Manual ,  dated  1  October 
1999,  gives  the  Weapon  System  Explosives  Safe¬ 
ty  Review  Board  (WSESRB)  the  technical  authori¬ 
ty  for  matters  concerning  Department  of  the  Navy 
(DON)  explosives  safety.  Enclosure  (1)  is  the  Explo¬ 
sives  Safety  Policy  Manual,  which  provides  18  chap¬ 
ters  of  explosives  safety  information,  ranging  from 
establishment  of  the  Explosives  Safety  Program  to 
Explosives  Mishap  Investigations  and  Reports. 
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This  instruction  provides  important  distinc¬ 
tions  for  programs  with  regard  to  when  they  will  be 
reviewed  by  the  WSESRB.  This  will  drive  the  PFS 
tasking  and  safety  schedule  working  lock  step  with 
the  system  developmental  plans  and  schedules.  The 
PFS  must  have  a  working  knowledge  of  the  over¬ 
all  development  schedule  to  ensure  that  the  safety 
program  is  being  reviewed  by  the  WSESRB  at  the 
appropriate  milestones. 

Naval  Sea  Systems  Command  (NAVSEA)  OP  4 

NAVSEA  OP  4,  Ammunition  and  Explosives 
Safety  Afloat ,  dated  1  July  2006,  is  the  mandatory 
instructions  and  regulations  for  safe  ammunition 
handling  and  ordnance  operations  aboard  ship. 
NAVSEA  OP  4  provides  technical  direction  and 
procedures,  including  ship  design  requirements 
and  standards  for  the  safe  handling,  stowage,  and 
use  of  all  ammunition  and  explosives  afloat.  It  is 
applicable  to  all  ships  owned  or  operated  by  the 
Navy,  and  it  is  also  applicable  to  other  vessels— 
such  as  the  Military  Sealift  Command  (MSC)— 
which  carry  naval  ammunition  and  explosives. 

The  PFS  responsible  for  ordnance  handling, 
stowage,  and  use  must  thoroughly  study  and  know 
the  information  contained  in  OP  4  in  order  to  ef¬ 
fectively  analyze  risk  associated  with  ordnance 
items. 

Naval  Sea  Systems  Command  Instruction 
(NAVSEAINST)  5000.8 

This  instruction  of  21  July  2008,  Naval  SYS- 
COM  Risk  Management  Policy ,  defines  the  require¬ 
ments  for  system  safety,  as  well  as  programmatic 
risk  for  naval  services,  which  includes: 

•  Naval  Sea  Systems  Command 

•  Naval  Air  Systems  Command 

•  Naval  Supply  Systems  Command 

•  Naval  Facilities  Engineering  Command  and 

•  Marine  Corps  Systems  Command 

The  instruction  perpetuates  policy  and  assigns 
responsibility  across  all  Naval  Systems  Commands 
(SYSCOMs)  and  affiliated  Program  Executive  Of¬ 
fices  (PEOs)  for  a  consistent  methodology  in  man¬ 
aging  risk.  It  discusses  system  safety  risk  and  the 
management  of  the  system  safety  process. 

For  the  PFS,  this  instruction  continues  the  ad¬ 
vancement  of  the  system-of-systems  safety  analysis 
concept  for  system  safety  assessments.  Few  pres¬ 
ent-day  systems  operate  in  a  stand-alone  environ¬ 
ment  with  no  integration  with  other  systems.  This 
facilitates  identifying  and  communicating  residual 
safety  risk  among  SYSCOMs.  It  also  helps  the  PFS 
communicate  risk  to  other  safety  programs  with 
which  they  interface. 


NAVSEAINST  51 00. 12 A 

NAVSEAINST  5100. 12A,  Requirements  for  Na¬ 
val  Sea  Systems  Command  System  Safety  Program 
for  Ships ,  Shipborne  Systems  and  Equipment ,  dat¬ 
ed  11  December  1995,  provides  guidance  to  NAV¬ 
SEA  directorates,  PEOs,  PMs,  and  MAs  on  setting 
up  and  tailoring  safety  programs  for  ships,  ship- 
borne  systems,  and  equipment.  Section  7.d  of  this 
instruction  provides  the  requirements  and  respon¬ 
sibilities  for  the  Naval  Ordnance  Safety  and  Securi¬ 
ty  Activity  (NOSSA)  (formerly  known  as  the  Naval 
Ordnance  Center).  One  of  those  requirements  spe¬ 
cifically  calls  out  the  provision  of  the  WSESRB 
chair. 

Enclosure  (1)  of  this  instruction  provides  guid¬ 
ance  to  the  PFS  on  tailoring  system  safety  program 
requirements,  but  the  PFS  should  be  cautioned  on 
the  outdated  concepts  and  requirements  recom¬ 
mended.  The  PFS  should  read  this  document  in  its 
entirety.  It  is  an  easy  read  and  helps  distinguish,  for 
the  PFS,  the  responsibilities  of  managing  activities. 

NAVSEAINST  8020.6E 

NAVSEAINST  8020. 6E,  Department  of  the 
Navy  Weapon  System  Explosives  Safety  Review 
Board ,  of  1 1  March  2008  defines  WSESRB  process¬ 
es  and  procedures  for  the  conduct  of  weapons-  and 
ordnance-related  safety  program  reviews.  Section 
8.i  gives  clear  guidance  on  the  responsibilities  and 
the  expectations  of  the  Program  PFS. 
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NAVSEAINST  9410.2 

NAVSEAINST  9410.2,  Naval  Warfare  Systems 
Certification  Policy ,  of  18  July  2005  is  a  naval  joint 
SYSCOM  instruction  that  defines  platform  certi¬ 
fication  criteria  for  ship  platform  and  strike  force 
combat  systems  in  support  of  the  Fleet  Response 
Plan  processes.  It  includes  combat  system  safety 
and  force  level  safety  as  a  requirement  in  the  re¬ 
view  process. 

The  PFS  that  has  the  responsibility  for  com¬ 
bat  systems,  platforms,  and  strike  force  (force  lev¬ 
el)  will  be  required  to  define  risk  for  the  decision 
makers  certifying  these  platforms.  Although  steps 
have  been  made  in  the  area  of  combat  system  safe¬ 
ty  risk  definition,  identification,  and  methodology, 
the  area  of  force  level  and  platform  safety  is  new 
and  emerging  for  the  safety  community. 

Guidance  and  Policy 

System  Safety  Program  Requirements 

MIL-STD-882C,  System  Safety  Program  Re¬ 
quirements ,  dated  19  January  1993,  is  the  over¬ 
arching  document  that  guides  government  and 
contractor  safety  programs.  It  specifies  the  an¬ 
alytical  tasks  that  should  be  performed  when 


conducting  a  comprehensive  safety  program.  MIL- 
STD-882C  does  a  good  job  of  guiding  the  safety 
team  on  what  needs  to  be  done,  but  the  currently 
approved  version,  882D,  is  lacking  in  the  “how-to” 
area  for  generation  of  the  safety  analysis  products. 

The  PFS  needs  to  be  familiar  with  both  the  D 
version  and  its  predecessor,  MIL-STD-882C.  The 
C  version  of  the  document  provides  the  PFS  with 
some  of  the  analytical  detail  lacking  in  D,  while  D 
offers  stronger  guidance  in  the  hazard/mishap  re¬ 
lationship. 

Weapon  System  Safety  Guidelines  Handbook 

NAVSEA  SW020-AH-SAF-010,  Weapon  Sys¬ 
tem  Safety  Guidelines  Handbook ,  is  a  comprehen¬ 
sive  handbook  that  provides  more  of  the  “how-to” 
with  regards  to  safety  analytical  tasks,  in  contrast  to 
the  MIL-STD-882  guidance.  This  guidelines  hand¬ 
book  provides  DON  best  practice  for  the  develop¬ 
ment  of  a  System  Safety  Program  in  accordance 
with  MIL-STD-882,  and  provides  the  manage¬ 
ment  and  technical  principles  of  systems  safety  en¬ 
gineering.  The  context  of  the  handbook  provides 
a  wealth  of  analytical  techniques  that  the  PFS  and 
safety  engineer  can  utilize  and  tailor  according  to 
the  needs  of  their  safety  program. 
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WSESRB  Interactive  Safety  Environment  (WISE) 

NOSSA  has  implemented  an  online  interaction 
safety  learning  tool  called  WISE.  This  online  curric¬ 
ulum  has  a  wealth  of  system  safety  information  and 
data.  It  represents  a  safety  knowledge  management 
tool  for  the  execution  of  any  system  safety  pro¬ 
gram  for  the  DON.  The  tool  allows  the  WSESRB  to 
promote  safety  practices  more  effectively  by  wide¬ 
ly  communicating  best  practices,  tacit  knowledge, 
and  supporting  system  safety  certification  require¬ 
ments  for  U.S.  Navy  and  Marine  Corps  PFSs.  The 
completion  of  the  WISE  curriculum  is  planned  as 
a  minimum  requirement  for  the  certification  of  a 
PFS,  pending  release  of  NAVSEAINST  12410.5. 
The  WISE  online  tool  can  be  accessed  at:  https:// 
nossa.nmci.navy.mil/wise/WISE  home.aspx 

Software  System  Safety  Handbook 

The  Joint  Software  System  Safety  Committee  re¬ 
leased  the  Software  System  Safety  Handbook  in  De¬ 
cember  1999.  The  generation  of  this  handbook  was 
a  joint  effort  developed  by  the  Joint  Services  Com¬ 
puter  Resources  Management  Group,  the  U.S.  Navy, 
the  U.S.  Army,  and  the  U.S.  Air  Force.  The  handbook 
was  developed  to  “provide  management  and  engi¬ 
neering  guidelines  to  achieve  a  reasonable  level  of 


assurance  that  software  will  execute  within  the  sys¬ 
tem  context  with  an  acceptable  level  of  safety  risk.” 

For  the  safety  engineer  or  PFS  that  deals  with 
software  controls  within  their  system,  this  is  the 
guidance  to  follow.  Fewer  and  fewer  systems  are  de¬ 
veloped  today  without  some  type  of  software  con¬ 
trols.  Whether  it  is  a  computer  chip  preprogrammed 
with  a  few  lines  of  firmware  or  millions  of  lines  of 
computer  code,  all  software  must  be  analyzed  for 
its  contribution,  or  lack  of  mitigations,  to  hazards. 
This  handbook  puts  the  PFS  on  a  path  to  analyze 
the  safety  criticality  of  software,  along  with  the  haz¬ 
ard  analysis  techniques  and  tools  to  get  there. 

Conclusion 

Although  this  article  has  provided  the  PFS  with 
a  list  of  policies  and  guidance  for  conducting  a  sys¬ 
tems  safety  engineering  program,  it  is  not  exhaus¬ 
tive.  Each  program  will  have  its  unique  requirements 
in  accordance  with  specific  acquisition  milestones 
from  concept  development  through  sustainment 
and  disposal.  The  area  of  systems  safety  engineering 
can  be  a  fulfilling  systems  engineering  discipline  for 
the  analyst  or  engineer.  It  can  be  very  rewarding  in 
the  benefits  that  it  provides  to  PMs,  system  design¬ 
ers,  MAs,  and  most  importantly,  to  the  warfighter. 
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By  Mike  Zemore  and  Etienne  (Steve)  Boscovitch 


♦  System  Designs 

♦  Materials 

♦  Functions  and  Functional  Allocations 

♦  Computer  Programs 

♦  Interfaces  (e.g.,  digital,  electrical, 

mechanical,  human/machine) 

♦  Fuels 

♦  Propellants 

♦  Chemicals 

♦  System  Life  Cycle 

♦  Faults 

♦  Fault  Tolerances 

♦  Redundancies 

♦  Operations 

♦  Operational  Procedures 

♦  System  Effects 

♦  Safety  Procedures 

♦  Human  Tendencies 

♦  Environmental  Effects 

♦  System  Disposal 


Systems  safety  engineering  is  an  engineering  discipline 
closely  related  to,  and  rooted  in,  systems  engineering.  How¬ 
ever,  training  in  systems  engineering  or  a  systems  engineering 
academic  degree  does  not  fully  prepare  employees  to  perform 
system  safety  analyses  within  the  framework  of  systems  safe¬ 
ty  engineering  standards,  methods,  and  techniques.  A  typical 
systems  safety  engineer  will  develop  to  become  an  expert  on 
the  elements  listed  in  the  shaded  box  to  the  left. 

Training  an  individual  to  conduct  the  requisite  analyses 
for  a  given  system  has  historically  taken  years  of  on-the-job 
training  and  individual  mentoring.  Todays  engineering  en¬ 
vironment  forces  the  acceleration  of  system  safety  training, 
leveraging  academic  opportunities  and  computer  Internet- 
accessible,  online  capabilities.  This  article  will  discuss  several 
opportunities  available  for  introductory  training  in  Navy  sys¬ 
tems  and  systems  safety  engineering.  The  impact  will  be  en¬ 
hanced,  expedited,  self-directed  weapon  system/system  safety 
training  applicable  to  naval  weapons  and  weapon  systems. 
Stakeholders  will  benefit  with  increased  knowledge  from 
their  systems  safety  engineer,  thus  reducing  the  costs  of  sys¬ 
tems  safety  engineering  analyses  and  enhancing  the  safety  of 
deployed  systems. 

The  Naval  Surface  Warfare  Center,  Dahlgren  Division,  Sys¬ 
tems  Safety  Engineering  Divisions  (NSWCDD/G70s)  func¬ 
tion  is  to  plan  and  perform  systematic  and  rigorous  systems 
safety  engineering  analyses  for  naval  warfare  systems.  The  ob¬ 
jective  is  to  predict,  assess,  and  mitigate  potential  harm  to  per¬ 
sonnel,  equipment,  and  the  environment  through  all  system 
life-cycle  phases.  The  division  comprises  three  branch-level 


50 


Naval  Sea  Systems  Command 


Training  the  Systems  Safety  Engineer 


focal  areas:  Engagement  System,  Combat  System, 
and  Platform  System.  Together,  the  division  leads 
the  way  for  systems  safety  engineering  on  surface 
naval  weapon  systems  including: 

•  Gun  systems 

•  Launchers 

•  Missile  systems 

•  United  Stated  Marine  Corps  (USMC)  weapons 

•  Integrated  surface  ship  combat  systems 

•  Surface  ship  topside  pointing  and  firing  zones 

•  Lasers 

•  Unmanned  systems 

•  Ground  platforms 

•  Integrated  surface  ship  platforms 

Given  the  importance  of  system  safety,  the  di¬ 
vision  has  embarked  on  a  series  of  robust  train¬ 
ing  activities  to  accelerate  the  learning  process  in 
support  of  customers  and  stakeholders.  The  fleet, 
program  managers,  program  executive  office,  and 
the  Naval  Ordnance  Safety  and  Security  Activity 
(NOSSA)  remain  the  primary  customers.  There¬ 
fore,  the  goal  is  to  ensure  that  these  customers 
have  the  clearest  view  of  safety  dispositions  and 
recommendations  based  on  reliable  systems  safe¬ 
ty  engineering  analyses.  The  challenge  is  train¬ 
ing  professionals  to  become  system  safety  experts, 
such  that  they  can  perform  reliable  safety  analyses 
on  the  elements  shown  in  the  shaded  box  on  the 
previous  page.  Skills  and  knowledge  in  these  areas, 


combined  with  sound  systems  safety  engineering 
methods,  ensure  that  professionals  can  effectively 
support  the  customers  and  the  goal  of  producing 
and  deploying  safe  systems  for  the  fleet. 

In  recent  times,  new  training  opportunities 
have  presented  themselves  in  the  areas  of  Navy 
knowledge,  academics,  and  systems  safety  en¬ 
gineering.  Obviously,  this  occurred  through  the 
diligence  of  many  people  striving  to  ensure  that 
personnel,  whether  civilian  or  military,  have  ac¬ 
cess  to  training  materials  and  forums  designed  to 
enhance  and  improve  capabilities.  A  large  portion 
of  this  training  is  available  electronically  through 
self-guided  learning  sessions.  These  sessions  have 
proven  extremely  effective  as  the  foundational  ele¬ 
ments  of  systems  safety  engineering.  The  resourc¬ 
es— Navy  Knowledge  Online  (NKO),  academia, 
and  the  Weapon  System  Explosives  Safety  Review 
Board  (WSESRB)  Interactive  Safety  Environment 
(WISE)— are  available  to  the  safety  practitioner 
the  moment  they  commit  to  the  engineering  dis¬ 
cipline  and  are  the  focus  of  this  article.  Utilization 
of  these  resources,  in  conjunction  with  the  divi¬ 
sions  workforce  development  classroom  instruc¬ 
tion,  provides  the  safety  practitioner  a  relevant  and 
robust  training  experience.  The  training  opportu¬ 
nities  available  to  the  safety  practitioner  with  appli¬ 
cability  to  the  systems  safety  engineering  discipline 
are  shown  in  Figure  1. 
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Figure  1.  Training  Opportunities  for  the  Safety  Practitioner 


NKO  is  utilized  throughout  the  Navy  fleet  and 
Navy  schools  as  part  of  a  multidisciplinary  man¬ 
agement  approach  that  strategically  applies  learn¬ 
ing  and  organizational  development  disciplines 
towards  the  goal  of  improving  both  performances 
and  efficiencies.  Knowledge  management  is  the  key 
to  bringing  the  right  information  to  the  right  peo¬ 
ple  at  the  right  time. 

NKO  does  not  provide  specific  online  training 
for  systems  safety  engineering,  as  would  be  need¬ 
ed  to  develop  in-depth  knowledge  of  systems  safety 
engineering  principles.  However,  NKO  does  pres¬ 
ent  a  multitude  of  self-guided  studies  to  establish 
the  foundational  understanding  of  Navy  systems, 
specific  designs,  operational  considerations,  and 
maintainability.  An  example  is  the  condensed  list¬ 
ing  of  combat  system  “A”  schools  shown  in  Figure  2. 
An  “A”  school  is  the  Navy  term  for  skill  training. 
Through  this  online  capability,  safety  practitioners 
are  able  to  receive  a  specific  knowledge  of  any  com¬ 
bat  system  lesson  to  expand  their  system  knowl¬ 
edge.  This  system  knowledge  greatly  assists  in  the 
development  of  comprehensive  and  complete  sys¬ 
tem  safety  assessments. 

Delving  down  to  specific  combat  system  com¬ 
ponents,  safety  practitioners  can  access  specific 
“A”  schools  and  community-of-practice  (CoP)  les¬ 
sons  to  acquire  detailed  understanding  of  system 


designs  and  functionality.  For  example,  if  a  safety 
analysis  is  intended  for  a  radar  system,  the  prac¬ 
titioner  can  access  basic  radar  systems  theory  to 
better  understand  radar  functionality  and  then  fol¬ 
low  up  with  CoP  lessons  to  understand  design  and 
use  details.  The  CoP  also  provides  access  to  subject 
matter  experts  (SMEs),  the  mechanism  for  elec¬ 
tronic  discussions,  support,  solutions,  and  lessons 
learned. 

By  utilizing  NKO,  the  division  has  tapped  into 
the  Navys  Electronic  Learning  (E-Learning)  envi¬ 
ronment  in  order  to  expedite  building  the  foun¬ 
dations  of  Navy  principles,  system  designs,  and 
operational  uses. 

Formal  degree  programs  from  accredited  col¬ 
leges  and  universities  also  provide  G70’s  capabil¬ 
ities  in  the  science  and  engineering  fields.  Unlike 
many  disciplines,  systems  safety  engineering  cross¬ 
es  many  boundaries  when  considering  the  me¬ 
chanics,  materials,  architectures,  software  control, 
electrical,  electronics,  integration,  and  environment 
of  any  system  or  collection  of  systems.  Fortunately, 
academic  programs  establish  the  fundamental  con¬ 
cepts  and  provide  an  avenue  for  comprehension  as 
the  multifaceted  science  and  engineering  princi¬ 
ples  are  applied  by  the  system  safety  practitioner. 
Advanced  degrees  further  the  capability  while  fa¬ 
cilitating  research  as  a  fundamental  objective  that 
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“A”  Schools  Page 

+ 

1 

Apprentice  Technical  (ET)  A  CoP 

+ 

— 

Apprentice  Technical  (FC)  A  CoP 

+ 

H 

Apprentice  Technical  (GM/TM)  A  CoP 

+ 

STG  A  School  CoP 

Figure  2.  Condensed  Listing  of  Combat  System  “A”  Schools 


can  be  focused  and  applied  in  the  field  of  system 
safety. 

NSWCDD  does  not  endorse  one  specific  de¬ 
gree  program  since  each  program  offers  the  prac¬ 
titioner  a  unique  perspective  and  knowledge  set 
needed  within  the  systems  safety  engineering  dis¬ 
cipline.  However,  it  is  true  that  systems  safety  engi¬ 
neering  closely  aligns  with  the  concepts,  principles, 
and  engineering  rigor  of  the  systems  engineering 
program.  The  National  Aeronautics  and  Space 
Administration  (NASA)  definition,  provided  be¬ 
low,  does  an  excellent  job  communicating  the  big 
picture  of  systems  engineering.  Adding  the  word 
“safety”  to  read  “Systems  safety  engineering  is  a  ro¬ 
bust...”  yields  a  good  understanding  for  systems 
safety  engineering  and  its  integration  and  align¬ 
ment  within  the  systems  engineering  process. 

Systems  engineering  is  a  robust  approach 
to  the  design,  creation,  and  operation  of  sys¬ 
tems.  In  simple  terms,  the  approach  consists 
of  identification  and  quantification  of  system 
goals,  creation  of  alternative  system  design 
concepts,  performance  of  design  trades,  se¬ 
lection  and  implementation  of  the  best  de¬ 
sign,  verification  that  the  design  is  properly 
built  and  integrated,  and  post-implementa¬ 
tion  assessment  of  how  well  the  system  meets 
(or  met)  the  goals.— NASA  Systems  Engineer¬ 
ing  Handbook,  1995,  SP-610S. 

Beyond  traditional  degree  programs,  there 
are  several  opportunities  for  the  safety  practitio¬ 
ner  to  gain  relevant  training  within  the  academ¬ 
ic  environment.  Historically,  training  in  this  area 
has  focused  on  Occupational  Safety  and  Health 
Administration  (OSHA)  requirements.  While  ex¬ 
tremely  important,  OSHA-specific  training  does 
not  encompass  the  essence  of  systems  safety  en¬ 
gineering  as  applied  to  acquisition  programs  and 
weapon  system  safety.  Fortunately,  there  has  been 


movement  over  the  years  to  offer  expanded  cur- 
riculums  that  include  systems  safety  engineer¬ 
ing  methods.  Obviously,  safety  training — whether 
OSHA  or  systems  safety  engineering  focused— can 
enhance  the  effort  and  add  value  for  the  practitio¬ 
ner,  customer,  and  user.  A  number  of  universities 
(see  Figure  3)  now  offer  safety- related  courses,  cer¬ 
tificates,  and  degrees.  Examples  are: 

•  System  Safety  in  Systems  Engineering  course 

♦  Defense  Acquisition  University 

•  System  Safety  course 

♦  University  of  Southern  California 

•  Software  Safety  course 

♦  University  of  Southern  California 

•  System  Safety  certificate 

♦  University  of  Southern  California 

•  Master  of  Science  degree  in  Safety  Sciences 

♦  Indiana  University  of  Pennsylvania 

•  Master  of  Science  degree  program  in  Envi¬ 
ronmental,  Health,  and  (workplace)  Safety 
Management 

♦  Rochester  Institute  of  Technology 

•  Master  of  Science  degree  program  in  Occupa¬ 
tional  and  Environmental  Safety  and  Health 

♦  University  of  Washington-W,  School  of 
Graduate  Studies 

•  Master  of  Science  degree  program  in  Health 
and  Safety,  with  a  Specialization  in  Occupa¬ 
tional  Safety  Management 

♦  Indiana  State  University,  Distance  Learning 

While  NKO  and  academia  support  the  over¬ 
all  systems  safety  engineering  objective,  there  re¬ 
mains  no  formal  training  or  certification  process 
for  system  safety  practitioners.  That  has  led  to  a 
NOSSA-sponsored  program  to  develop  a  Web-based 
E-Learning  tool  targeting  safety  practitioners  and 
acquisition  customers  that  fall  under  the  purview 
of  the  WSESRB.  Given  the  thrust  to  establish  a  sys¬ 
tems  safety  engineering  certification  program,  this 
E-Learning,  called  WISE,  provides  the  capability 
as  an  electronically  accessible  tool  to  capture  and 
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communicate  safety  processes  while  testing  and 
potentially  certifying  safety  practitioners  at  multi¬ 
ple  levels  of  responsibility.  The  mission  statement 
for  WISE  is  documented  as  follows: 

To  develop  a  Web-based  Safety  Engineer¬ 
ing  Environment  that  will  facilitate  execution 
of  Navy  weapon  systems  and  ordnance  safety 
processes  and  procedures,  provide  safety 
practitioner  training,  and  establish  certifica¬ 
tion  management  for  individuals  serving  as 
Principals  for  Safety  (PFS)  for  naval  and  Ma¬ 
rine  Corps  programs. 

Developed  by  EG&G  under  the  guidance 
and  direction  of  the  NOSSA,  the  WISE  program 
provides  open  access  as  a  centralized  reposito¬ 
ry  of  safety  knowledge  and  training  as  an  efficient 
means  of  learning  and  understanding  system  safe¬ 
ty.  Each  WISE  training  module  is  designed  to  in¬ 
crease  knowledge  and  comprehension  of  system 


safety  processes  for  application  within  an  acqui¬ 
sition  program.  The  E-Learning  capability  comes 
without  cost  to  the  safety  practitioner  or  sponsoring 
program  office.  This  approach  supports  the  initia¬ 
tive  to  facilitate  training  and  use  of  consistent  sys¬ 
tem  safety  methodologies  within  the  Department  of 
the  Navy  (DON)  with  minimal  or  no  impact  to  pro¬ 
gram  cost  or  schedule.  The  expectation  is  that  this 
investment— applied  across  DON  programs— will 
enhance  the  safety  of  the  systems  deployed  and  ease 
the  process  for  WSESRB  review.  A  snapshot  of  the 
WISE  home  page  is  shown  as  Figure  4. 

G70  continues  to  strive  towards  excellence 
when  training  new  practitioners  in  systems  safe¬ 
ty  engineering  and  in  performing  system  safety 
analyses.  With  the  ever-changing  workplace  envi¬ 
ronment,  it  makes  sense  to  evolve  while  utilizing 
the  capabilities  of  NKO  and  WISE  for  training  op¬ 
portunities.  This,  coupled  with  academic  offerings, 
provides  the  practitioner  the  knowledge,  skills,  and 
abilities  for  system  safety  analysis  efforts. 
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Establishing  and  Training  Best  Practices 
in  Systems  Safety  Engineering 

By  Robert  C.  Heflin  Jr. 


This  article  serves  as  a  follow-on  to  the  previous  article ,  which  discussed  some  of  the 
challenges  involved  in  training  systems  safety  engineers ,  and  some  of  the  ways  in  which 
those  challenges  are  being  met.  Whereas  that  article  focused  more  on  the  external  and  elec¬ 
tronic  opportunities  available ,  this  article  will  explore  the  currently  ongoing  training  efforts 
internal  to  the  Systems  Safety  Engineering  Division  designed  to  develop  and  implement 
training  in  safety  analysis  best  practices  as  developed  within  the  division. 

Locating  and  recruiting  trained  systems  safety  engineers  has  traditionally  been  a 
significant  challenge.  Though  systems  safety  engineering  is  a  discipline  within  systems 
engineering,  few  institutes  of  higher  learning  provide  specific  systems  safety  engineer¬ 
ing  instruction.  Therefore,  only  a  small  number  of  college  graduates  emerge  each  year 
with  an  understanding  of  what  system  safety  is  about.  While  a  new  crop  of  computer 
scientists,  electrical  engineers,  mathematicians,  etc.,  graduate  each  year  and  enter  the 
workforce  able  to  hit  the  ground  running  in  most  career  fields,  scientists  and  engineers 
who  land  in  system  safety  are  often  confronted  with  unique  and  challenging  concepts 
that  their  academic  training  has  not  exposed  them  to.  Over  the  past  several  years,  the 
Systems  Safety  Engineering  Division  (G70)  of  the  Naval  Surface  Warfare  Center,  Dahl- 
gren  Division  (NSWCDD)  has  implemented  a  series  of  efforts  geared  toward  develop¬ 
ing  and  standardizing  best  practices  in  the  implementation  of  system  safety  analysis, 
and  providing  detailed  systems  safety  engineering  training,  in  utilizing  those  practices, 
to  the  entire  division  workforce,  as  well  as  to  support  contractor  personnel. 

The  centerpiece  of  these  efforts  is  known  as  the  Workforce  Development  Project, 
referred  to  as  WFD.  The  initiative  grew  from  a  Lean  Six  Sigma  Value  Stream  Analy¬ 
sis  (VSA)  of  the  system  safety  analysis  process  as  practiced  within  G70.  The  VSA  was 
chartered  to  examine  the  business  model  and  technical  processes  utilized  within  G70 
in  performing  systems  safety  engineering  for  the  Department  of  Defense  (DoD),  pro¬ 
ducing  the  necessary  artifacts  to  document  the  results  of  those  analyses  and,  ultimately, 
ensuring  the  deployment  of  safe  systems  for  our  military  forces.  During  the  VSA,  G70 
senior  management  and  technical  personnel  deconstructed  the  overall  system  safety 
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analysis  process  as  ideally  practiced  and  identified 
34  separate  areas  of  focus  that  participants  con¬ 
curred  are  key  elements  in  performing  consistent, 
high-quality  safety  analysis.  While  most  of  these 
areas  fell  within  the  technical  analysis  process  it¬ 
self,  others  were  associated  more  closely  with  as¬ 
sociated  functions,  such  as  communication  and 
training.  During  discussions  on  how  to  best  per¬ 
form  each  of  these  focus  areas,  it  quickly  became 
apparent  that  insufficient  formalized  training  was 
the  most  significant  impediment  G70  faced  in  en¬ 
suring  the  performance  of  consistently  high-qual¬ 
ity  system  safety  analyses.  It  was  recognized  that 
training  in  system  safety  analysis  had  traditionally 
been  conducted  on  an  informal,  one-to-one  basis 
by  senior  engineers  mentoring  junior  engineers. 
Over  the  course  of  decades—  as  systems  became 
more  and  more  complex,  new  technologies  were 
introduced,  and  computer  programs  were  heavily 
relied  upon  to  control  weapon  and  ordnance  sys¬ 
tems— systems  safety  engineering  methodologies 
and  practices  were  not  consistently  evolving  or  be¬ 
ing  practiced  across  the  division. 

Addressing  the  issue  thus  necessitated  a  two¬ 
pronged  approach.  First,  safety  analysis  method¬ 
ologies  within  G70  needed  to  be  standardized, 
and  second,  a  process  for  training  personnel  in 
those  methodologies  on  a  consistent  basis  needed 
to  be  formalized.  To  accomplish  the  former,  G70 


embarked  on  a  series  of  Lean  events  aimed  at  de¬ 
veloping  a  concise  and  consistent  process  for  safe¬ 
ty  analysis  implementation  and  documentation. 
Over  a  24-month  period,  individual  events  were 
conducted  for  each  of  the  34  identified  focus  ar¬ 
eas.  Each  event  included  personnel  from  each  of 
the  three  branches  within  the  division,  as  well  as 
contractor  support  personnel  and  customer  rep¬ 
resentatives  wherever  possible.  These  events  re¬ 
viewed  existing  methodologies  for  performing 
and/or  documenting  different  major  elements 
within  the  overall  system  safety  process,  and  es¬ 
tablished  and  documented  a  single  best-practice 
methodology  for  each  of  those  elements.  This  best 
practice  was  accepted  as  part  of  the  official  consol¬ 
idated  G70  safety  analysis  process. 

The  largest  and  most  significant  of  the  34  fo¬ 
cus  areas  identified  in  the  VSA  became  the  basis 
for  addressing  the  second  part  of  the  problem- 
training  the  workforce.  The  WFD  was  initiated 
immediately  following  the  VSA  and  ran  concur¬ 
rently  with  the  other  focus  area  Lean  events  over 
the  2-year  period.  The  objectives  of  the  WFD  were 
to  identify  the  primary  training  needs  with  the  di¬ 
vision  and  to  develop  necessary  strategies  and  ma¬ 
terials  to  meet  those  needs.  The  team  researched 
in  detail  the  system  safety  training  already  avail¬ 
able,  both  commercially  and  within  the  govern¬ 
ment.  Mindful  of  training  budget  constraints,  care 
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was  exercised  to  avoid  “reinventing  the  wheel”  by 
ensuring  that  currently  available  training  was  uti¬ 
lized  wherever  prudent,  and  that  effort  was  not 
duplicated  in  developing  materials  for  already 
available  training.  The  WFD  team  divided  their 
objectives  into  short-  and  long-term  needs.  For 
the  short  term,  effort  was  focused  on  providing 
necessary  high-level  foundational  instruction  on 
the  overall  safety  analysis  process  and  the  types  of 
systems  on  which  G70  practices  safety  analysis  in  a 
structured  classroom  environment.  The  currently 
ongoing  longer  term  effort,  known  as  WFD  Phase 
II,  is  aimed  at  providing  the  detailed  instruction 
necessary  to  allow  the  systems  safety  engineer  to 
implement  the  methodologies  and  best  practices 
developed  by  the  organization  through  the  focus 
area  events,  in  conducting  a  thorough  system  safe¬ 
ty  analysis  on  any  given  system. 

To  accomplish  the  short-term  goal  of  provid¬ 
ing  a  high-level  foundation  of  systems  and  system 
safety  knowledge,  the  WFD  team  developed  a  cur¬ 
riculum  consisting  of  six  classes.  These  six  classes 
focused  on  introducing  the  students  to  U.S.  Navy 
and  U.S.  Marine  Corps  systems,  describing  sys¬ 
tem  safety  concepts  at  a  high  level  and  detailing 
the  overall  system  safety  analysis  process  as  de¬ 
signed  for  practice  within  G70.  Each  class  was  of¬ 
fered  on  multiple  dates  and  times  over  a  6-month 
period  to  the  existing  workforce  and  planned  for 


further  future  periodic  iterations  to  account  for 
workforce  expansion  and  turnover.  Attendance 
was  mandatory  for  some  of  the  classes  and  volun¬ 
tary  for  others,  as  necessitated  by  the  importance 
of  the  material  being  presented  and  the  topical  fa¬ 
miliarity  of  individual  safety  engineers. 

As  the  target  audience  for  these  classes  com¬ 
prised  professionals,  subject  matter  testing  was 
not  deemed  an  appropriate  method  of  verifying 
comprehension  and  understanding.  Instead,  the 
idea  of  self-certification  was  introduced.  Under 
this  paradigm,  students  are  required  to  judge  for 
themselves  when  they  have  mastered  the  informa¬ 
tion  presented.  At  that  time,  they  inform  one  of 
several  designated  recordkeepers,  who  ensure  that 
a  master  WFD  database  is  updated  to  reflect  that 
certification.  During  each  class,  students  were  pro¬ 
vided  with  multiple  contacts  considered  to  be  sub¬ 
ject  matter  experts,  who  were  available  throughout 
the  6-month  period  to  aid  in  the  understanding  of 
concepts  being  discussed.  In  this  fashion,  the  en¬ 
tire  workforce  was  brought  relatively  quickly  to  a 
common  level  of  basic  understanding  of  the  spec¬ 
ified  concepts. 

Once  the  workforce  had  achieved  these  short¬ 
term  goals  of  understanding,  Phase  II  of  the  WFD 
project  was  entered  and  is  currently  ongoing.  The 
goal  of  Phase  II  is  to  develop  and  implement  an  in¬ 
struction  process  through  which  the  workforce  is 
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educated  in  how  to  apply  each  of  the  best  practic¬ 
es  previously  developed  during  their  system  safety 
analyses.  The  plan  for  this  phase  of  WFD  is  to  de¬ 
velop  a  fictitious  system  and  to  conduct  a  complete 
safety  analysis  on  that  system  via  a  series  of  work¬ 
shops,  which  will  encompass  each  of  the  elements 
of  the  safety  analysis  process  for  which  an  individ¬ 
ual  focus  area  Lean  event  was  conducted.  Develop¬ 
ment  of  a  useable  representative  system  will  require 
development  of  not  only  a  design  for  the  system,  but 
also  all  associated  documentation  typically  associ¬ 
ated  with  the  systems  analyzed  in  G70,  including 
but  not  limited  to,  a  Concept  of  Operations,  System 
Development  Specification,  Interface  Design  Doc¬ 
ument,  maintenance  and  user  documentation,  etc. 

The  workshops  will  include  instruction  in 
methodology  by  senior  division  personnel  and  su¬ 
pervised  group  projects  implementing  the  meth¬ 
odology  for  executing  the  specific  aspect  of  safety 
analysis  being  taught.  Each  workshop  will  be  con¬ 
ducted  several  times  in  order  to  include  all  division 
personnel.  As  the  system  safety  analysis  process  is 
one  in  which  each  step  builds  upon  the  product 
of  the  previous  steps,  at  the  conclusion  of  instruc¬ 
tion  for  each  aspect  of  the  process,  the  products  of 
all  groups  will  be  meshed  into  a  single,  compre¬ 
hensive  analysis  product  for  the  system,  which  will 
then  be  carried  forward  as  an  input  into  the  next 
series  of  workshops. 


The  example  system  under  development  for 
use  in  these  workshops  is  designed  to  be  rela¬ 
tively  simple  to  understand  while  simultaneous¬ 
ly  encompassing  design  aspects  of  many  similar 
systems  G70  personnel  are  currently  analyzing.  In 
this  way,  the  system  will  be  easily  relatable  to  by 
students  with  varying  degrees  of  systems  and  sys¬ 
tem  safety  experience.  Once  a  safety  engineer  has 
completed  the  entire  workshop  series,  he  or  she 
will  be  well-versed  in  the  G70  best  practice  meth¬ 
odology  for  conducting  every  significant  aspect  of 
the  system  safety  analysis  process.  Once  complet¬ 
ed  and  implemented,  the  workshop  series  will  be 
repeated  periodically  as  needed  as  the  workforce 
changes  and  will  be  updated  as  new  techniques 
and  technologies  emerge  to  evolve  the  safety  anal¬ 
ysis  process. 

Establishing  best  practices  and  training  for  the 
workforce  in  a  consistent  and  repeatable  method¬ 
ology  for  implementing  those  practices  is  a  formi¬ 
dable  task  in  any  discipline.  In  system  safety,  where 
limited  formal  education  is  available  outside  of  the 
offices  of  the  practitioners,  it  is  particularly  daunt¬ 
ing.  However  the  Systems  Safety  Engineering  Divi¬ 
sion  is  facing  this  task  with  a  unique  and  consistent 
solution,  which  will  provide  the  capability  to  train 
the  division  workforce  and  help  ensure  the  safety 
of  our  weapon  systems  and,  thus,  of  those  who  use 
them  to  defend  our  freedom. 
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Navy  Safety  Review  Boards: 
WSESRB,  SSSTRP,  AND  FISTRP 


By  Mary  Ellen  Caro ,  David  Shampine,  and  Jack  Waller 


In  1967 ,  an  electrical  anomaly  caused  a  Zuni  rocket  to  be  discharged  aboard  ship  during 
combat  operations  in  the  Gulf  of  Tonkin,  causing  the  worst  carrier  fire  since  World  War 
II  and  killing  134  Sailors.  The  Navys  response  was  a  concentrated  effort  to  address  safety 
and  establish  a  process  to  mitigate  the  chances  that  such  devastation  would  happen  again 
aboard  a  naval  vessel  Central  to  that  effort  was  the  establishment  of  an  independent  board 
comprising  subject  matter  experts  in  various  system  safety-related  disciplines  within  sys¬ 
tems  engineering,  to  provide  review  and  oversight  of  systems  executing  safety  programs. 
Over  time,  the  increasing  number  and  complexity  of  systems  under  development  led  to  the 
formation  of  more  specialized  subpanels  to  aid  the  board  in  that  effort.  The  articles  in  this 
section  of  the  Leading  Edge  describe  that  board  and  the  subpanels  that  subsequently  grew 
from  the  effort  to  ensure  that  U.S.  Navy  weapons  are  safe  to  develop  and  use. 
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carrier  was  on  station  off  Vietnam  and  killed  134  of  the  ship’s  crew. 


Firefighters  check  the  burned  out  hulk  of  an  A-4E  Skyhawk  destroyed  in  the  worst  fire  aboard 


a  U.S.  aircraft  carrier.  The  fire  erupted  aboard  USS  Forrestal  (CVA59)  on  29  July  1967  as  the 
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Software  System  Safety  Technical 
Review  Panel 
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Fuze  and  Initiation  System 
Technical  Review  Panel 


By  Mary  Ellen  Caro 


By  David  Shampine 


By  Jack  Waller 


At  sea  aboard  Precommissioning  Unit  (PCU)  Ronald  Reagan  (CVN  76) 
7  May  2003  -  The  Navy’s  newest  Nimitz-c\ass  aircraft  carrier  tests  its 
countermeasure  wash  down  systems  (CMWDS)  during  scheduled 
builder  sea  trials  off  the  coast  of  Virginia.  CMWDS  includes  a  series  of 
sprinklers  in  vital  areas  throughout  the  ship  to  help  contain  the  spread 
of  fire  or  chemical,  biological,  or  radiological  (CBR)  attacks. 

U.S.  Navy  photo  by  Photographer’s  Mate  2nd  Class  James  Thierry.  (RELEASED) 
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The  Navy’s  Weapon  System  Explosives 
Safety  Review  Board  (WSESRB) 


The  Navys  Weapon  System  Explosives  Safety 
Review  Board  (WSESRB)  serves  as  the  Navy’s  inde¬ 
pendent  oversight  body  for  weapons  and  explosives 
safety  The  scope  of  the  WSESRB  includes  weapon 
systems  being  developed  or  used  by  both  Navy  and 
Marine  Corps.  The  latest  draff  of  NAVSEAINST 
8020.6E,  Department  of  the  Navy  Weapon  System 
Explosives  Safety  Review  Board ,  signed  in  March 
2008,  also  gives  the  WSESRB  oversight  responsi¬ 
bility  for  directed- energy  weapons. 

The  WSESRB  was  originally  established  after 
a  series  of  catastrophic  explosive  events,  including 
USS  Forrestal  and  USS  Oriskany  conflagrations. 
The  loss  of  life  and  property  resulting  from  these 
mishaps  led  to  recommendations  from  boards  of 
inquiry  investigating  these  mishaps,  resulting  in 
the  establishment  of  the  WSESRB  in  1967  to  review 
the  explosives  safety  of  weapons.  The  WSESRB  is 
chartered  by  the  Chief  of  Naval  Operations  (CNO) 
to  provide  independent  oversight  of  the  Depart¬ 
ment  of  the  Navy’s  (DON’s)  weapon  program  safe¬ 
ty  efforts.  The  majority  of  programs  reviewed  by 
the  WSESRB  are  acquisition  programs  for  new  and 
upgraded  weapon  and  combat  systems. 

The  Chairperson  of  the  WSESRB  is  dual-hat- 
ted,  serving  as  the  Executive  Director  of  the  Naval 
Ordnance  Safety  and  Security  Activity  (NOSSA) 
and  as  Naval  Sea  Systems  Command  (NAVSEA) 
Director  of  Ordnance  Safety  (SEA  00 VW).  This 
position  also  carries  the  Technical  Warrant  for 
Weapon  Systems,  Ordnance,  and  Explosives— 
Safety  and  Security.  The  WSESRB  draws  support 
from  NOSSA’s  Weapons  System  Safety  Director¬ 
ate  (N3).  NOSSA  N3  provides  the  Vice  Chair  and 
Secretariat.  WSESRB  membership  is  composed  of 
representatives  from  each  of  the  major  Navy  Sys¬ 
tems  Commands,  Warfare  Centers,  fleet  represen¬ 
tatives,  the  Naval  Safety  Center,  the  Navy/Marine 
Corps  Public  Health  Center,  and  the  Navy  Explo¬ 
sives  Ordnance  Disposal  Technology  Center.  Spe¬ 
cific  technical  expertise  is  also  drawn  from  the 
Warfare  Centers  and  the  technical  warrant  holder 
(TWH)  community. 

As  part  of  the  weapon  development  process, 
the  WSESRB  also  looks  to  the  Ship  Weapon  In¬ 
tegration  Team  (SWIT),  composed  of  members 
of  NAVSEA  and  Naval  Air  Systems  Command 
(NAVAIR)  activities — to  ensure  that  the  weapon 
can  be  safely  handled  and  stowed  aboard  ship. 

The  ultimate  goal  of  the  WSESRB  is  to  ensure 
that  the  weapons  and  weapon  control  systems  that 
the  Navy  and  Marine  Corps  field  are  safe  for  the 
users.  The  Board  also  evaluates  weapon  systems 
developed  by  other  services  to  ensure  that  they 
are  safe  to  carry  and  operate  from  Navy  platforms. 


Early  engagement  of  the  WSESRB  review  process 
benefits  the  DON,  as  well  as  the  acquisition  pro¬ 
gram  manager  (PM).  Early  incorporation  of  safety 
requirements  and  allocation  of  resources  for  safety 
analysis  and  testing  allows  a  program  to  plan  and 
execute  the  weapon  system  safety  program  and  un¬ 
cover  safety  issues  when  they  are  less  expensive, 
and  solutions  are  easier  to  incorporate  into  the  sys¬ 
tem  design.  Late  identification  of  safety  issues  can 
have  a  significant  impact  on  cost  and  schedule  and 
can  pose  safety  risks  to  users. 

The  goal  of  the  WSESRB  is  to  ensure  that  dur¬ 
ing  development,  weapons  are  analyzed  and  test¬ 
ed  for  their  safety  characteristics.  Has  the  weapon 
been  exposed  to  all  of  the  environments  that  it  will 
likely  see  in  its  lifetime?  Are  there  any  safety  issues 
or  risks  resulting  from  these  analyses  and  tests?  Ar¬ 
eas  of  review  include: 

•  Energetic  material  qualification 

•  Hazard  assessment  tests 

•  Insensitive  munitions 

•  Electromagnetic  environmental  effects  test¬ 
ing,  including  Hazards  of  Electromagnetic 
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Radiation  to  Ordnance  (HERO)  and  electro¬ 
static  discharge 

•  Temperature  and  vibration  exposures 

•  Shipboard  shock  and  packaging  tests 

Two  areas  require  special  attention  for  the  sys¬ 
tems  that  the  Navy  is  currently  developing:  soft¬ 
ware  and  fuzing/initiation  systems.  More  software 
is  being  used  to  execute  safety-critical  functions 
within  weapons  or  within  the  systems  control¬ 
ling  their  selection  and  launch.  With  the  advent 
of  electronic  safe  and  arming  devices,  fuzing  sys¬ 
tems  have  become  more  complex,  and  their  safety 
functions  are  being  distributed  throughout  the  sys¬ 
tem  architecture.  For  these  reasons,  there  are  two 
subpanels  of  the  WSESRB:  the  Software  System 
Safety  Technical  Review  Panel  (SSSTRP)  and  the 
Fuze  and  Initiation  System  Technical  Review  Panel 
(FISTRP).  Acquisition  programs  brief  these  panels 
separately  from  the  WSESRB,  allowing  more  time 
to  be  spent  on  these  safety-critical  aspects  of  a  pro¬ 
gram.  The  SSSTRP  and  FISTRP  support  the  Board, 
and  their  findings  are  not  official  until  they  have 
been  approved  by  the  WSESRB. 

Weapon  acquisition  programs  come  before 
the  WSESRB  at  several  points  in  their  acquisition 
life  cycle  to  obtain  Board  concurrence  before  pro¬ 
ceeding  to  the  next  stage  of  development.  Normal¬ 
ly,  there  is  an  introductory  review  upon  a  contract 
award  to  assess  the  planned  safety  analysis  and 


testing  program.  This  review  can  benefit  PMs  in 
the  early  stages  of  a  program  acquisition  by  ensur¬ 
ing  the  needed  testing  and  analysis  are  available  by 
the  time  the  program  is  ready  to  proceed  to  pro¬ 
duction. 

Another  time  for  WSESRB  review  is  prior  to 
a  Critical  Design  Review  (CDR).  At  CDR,  the  de¬ 
sign  is  usually  frozen,  which  makes  changes  in  the 
design  to  eliminate  or  mitigate  a  safety  issue  diffi¬ 
cult  and  costly.  The  CDR  WSESRB  review  can  mit¬ 
igate  the  need  for  later  design  changes.  The  Board 
expects  programs  to  follow  MIL-STD-882  s  “Safety 
Order  of  Precedence”  in  the  mitigation  of  hazards 
and  risks.  Design  changes  to  eliminate  a  hazard  are 
preferable  to  installing  a  safety  device  (e.g.,  protec¬ 
tion  mechanism  such  as  a  guard),  which  in  turn,  is 
preferable  to  a  warning  device.  The  least  preferred 
method  of  risk  mitigation  is  the  use  of  training  and 
procedures.  Humans  make  errors,  and  even  a  small 
error  can  have  catastrophic  results  when  employ¬ 
ing  weapons  and  ordnance  systems. 

A  WSESRB  review  is  also  required  prior  to 
the  deployment  of  a  system  to  ensure  that  all  of 
the  safety  testing  and  analysis  has  been  complet¬ 
ed  with  no  unresolved  safety  issues.  At  this  time, 
the  risk  of  the  system  is  characterized,  docu¬ 
mented,  and  communicated  to  the  user  commu¬ 
nity.  It  is  also  a  review  where  the  board  ensures 
that  training  programs  have  been  established  and 
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documentation— in  the  form  of  operating  and 
maintenance  procedures— are  in  place  for  safe  op¬ 
eration  of  the  system. 

One  other  time  where  WSESRB  approval  is  re¬ 
quired  is  for  a  test  event  aboard  ship  where  devel¬ 
opmental  weapons  or  weapon  systems  are  being 
used.  This  is  one  area  where  the  fleet  will  see  the 
effects  of  the  WSESRB  process.  Acceptance  trials, 
Combat  System  Ship  Qualification  Trials,  and  pre¬ 
deployment  workups  are  some  of  the  events  re¬ 
quiring  WSESRB  approval. 

The  WSESRB  Secretariat  (NOSSA  N3)  is  avail¬ 
able  to  the  PMs  and  program  Principals  for  Safety 
to  coordinate  WSESRB  reviews.  Points  of  contact 
have  been  established  for  different  families  of 


weapon  systems.  The  Secretariat  staff  can  make 
recommendations  for  WSESRB  reviews  and  facili¬ 
tate  scheduling  Board  meetings.  Each  review  by  the 
WSESRB  (or  an  associate  board;  i.e.,  the  SSSTRP 
or  FISTRP)  requires  the  submission  of  a  technical 
data  package.  The  expectations  for  these  data  pack¬ 
ages  are  found  in  NAVSEAINST  8020. 6E. 

WSESRB  reviews  provide  Navy  and  Marine 
Corps  PMs  with  an  objective  assessment  of  their 
safety  program  from  a  panel  of  subject  matter  ex¬ 
perts.  This  review  is  the  Navy’s  focal  point  for  the 
prevention  of  mishaps  involving  ammunition,  ex¬ 
plosives,  and  related  systems— thereby  eliminating 
deaths,  injuries,  lost  workdays,  and  property  and 
environmental  damage. 


NAVSEA  Warfare  Centers 


Volume  7 ,  Issue  No.  3 


65 


Systems  Safety  Engineering 

The  Players 


The  Navy’s  Software  System  Safety 
Technical  Review  Panel  (SSSTRP) 


By  David  Shampine 


The  Software  System  Safety  Technical  Review  Panel 
(SSSTRP)  is  part  of  the  safety  team  at  the  Naval  Ordnance 
Safety  and  Security  Activity  (NOSSA)  and  was  organized  to 
support  the  Weapon  System  Explosives  Safety  Review  Board 
(WSESRB).  The  goal  sought  in  establishing  the  SSSTRP  is  to 
provide  a  more  thorough  review  of  the  complex  safety  issues 
related  to  software  control  of  systems  and  to  reduce  the  bur¬ 
den  on  both  the  program  office  and  the  WSESRB  in  the  re¬ 
view  of  systems  that  are  software  intensive  or  where  software 
is  the  only  issue  being  addressed.  In  addition,  the  SSSTRP 
may  be  used  in  lieu  of  interim  WSESRB  reviews  not  associ¬ 
ated  with  major  milestones.  Decisions  regarding  substitution 
of  the  SSSTRP  review  for  a  WSESRB  review  are  normally  de¬ 
cided  on  a  case-by-case  basis  by  the  WSESRB  Chairperson. 

WSESRB  meetings  are  scheduled  during  the  second  full 
week  of  each  month,  while  SSSTRPs  are  scheduled  during 
the  2-week  period  following  WSESRB  week.  The  majority  of 
program  offices  try  to  complete  an  SSSTRP  review  prior  to 
going  into  a  WSESRB  meeting.  The  SSSTRP  meeting  work¬ 
load  is  coordinated  by  the  SSSTRP  Team  to  be  in  concert 
with  the  WSESRB  agenda  during  regularly  scheduled  week¬ 
ly  meetings.  The  Systems  Safety  Engineering  Division  of  the 
Naval  Surface  Warfare  Center,  Dahlgren  Division  plays  a  sig¬ 
nificant  role  in  providing  technical  subject  matter  experts 
(SMEs)  as  panel  members  to  the  SSSTRP.  Other  organiza¬ 
tions— such  as  the  Naval  Undersea  Warfare  Center,  Newport 
and  the  Naval  Air  Warfare  Center,  China  Lake— also  provide 
SMEs  on  a  regular  basis.  These  panel  members  are  selected 
from  a  pool  of  professionals  with  backgrounds  in  computer 
science,  computer  engineering,  and  system  safety. 

In  preparation  for  an  SSSTRP  review,  the  program  of- 
>  a  detailed  Technical  Data  Package  (TDP)  that 
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has  been  developed  in  accordance  with  the  guide¬ 
lines  established  in  NAVSEAINST  8020. 6E,  Enclo¬ 
sure  8.  This  package  is  submitted  no  later  than  21 
days  in  advance  of  the  target  date  for  the  meeting. 
Once  the  TDP  is  received  by  the  WSESRB,  it  is  re¬ 
viewed  by  the  NOSSA  Point  of  Contact  and  the 
SSSTRP  Chairperson  for  technical  content  to  en¬ 
sure  it  meets  the  intended  guidelines,  and  the  for¬ 
mal  presentation,  if  required,  is  then  placed  on  the 
schedule.  If  the  Chairperson  determines  that  the  is¬ 
sues  pertinent  to  the  review  do  not  require  a  formal 
presentation,  the  program  may  be  allowed  to  pur¬ 
sue  its  purpose  via  letter.  In  such  a  case,  the  TDP 
is  allowed  to  stand  on  its  own  merit,  and  the  data 
is  disbursed  electronically  and  reviewed  by  panel 
members  individually. 

SSSTRP  meetings  consist  of  three  parts:  the 
pre-brief,  the  presentation,  and  the  caucus.  The 
pre-brief  is  conducted  by  the  Chairperson  and  is 
meant  to  set  the  tone  for  the  presentation.  Any 
preliminary  issues  discovered  by  panel  members 
during  the  review  of  the  TDP  are  discussed  dur¬ 
ing  the  pre-brief  and  are  identified  as  potential  fo¬ 
cus  points  for  discussion  during  the  presentation. 
The  presentation  is  scheduled  to  last  no  more  than 
6  hours,  with  the  program  office  being  responsi¬ 
ble  for  managing  both  the  content  and  the  time  to 
present  the  safety  case  for  the  system  under  review. 
The  caucus  immediately  follows  the  presentation, 
with  its  attendance  limited  to  the  panel  members 
and  the  programs  Principal  for  Safety.  During  this 
phase  of  the  process,  the  panel  members  discuss 


the  data  presented  in  the  data  package  and  during 
the  presentation,  and  then  develop  recommenda¬ 
tions  and  action  items  for  the  program  to  aid  in 
improving  their  safety  program.  At  the  end  of  the 
meeting,  the  program  representatives  are  provid¬ 
ed  with  a  draff  copy  of  the  results  of  the  review, 
with  the  caveat  that  it  is  not  final  until  approved 
by  the  WSESRB. 

Additionally,  the  SSSTRP  conducts  informal 
technical  assistance  meetings,  which  are  not  official 
meetings  and  need  not  be  reported  out  to  the  WS¬ 
ESRB.  This  is  an  opportunity  for  the  program  of¬ 
fice  to  obtain  guidance  and  advice  at  key  points  in 
time  within  the  acquisition  cycle.  There  are  no  min¬ 
utes  taken,  findings  assigned,  or  letter  generated  as  a 
result  of  the  meeting.  The  WSESRB  considers  tech¬ 
nical  assistance  meetings  an  informal  information 
exchange  to  assist  the  program  office  in  understand¬ 
ing  WSESRB  interpretation  of  safety  regulations, 
instructions,  and  policy.  These  meetings  are  not  in¬ 
tended  to  discuss  concurrence  with  program  office 
design,  development,  or  acquisition  goals. 

Since  its  inception,  the  SSSTRP  has  reviewed 
numerous  programs  in  its  role  as  the  software  arm 
of  the  WSESRB.  It  has  provided  for  these  systems 
a  detailed  review  of  their  software  safety  programs 
and  has  provided  technical  assistance  and  recom¬ 
mendations  for  improving  the  depth  and  quali¬ 
ty  of  their  software  safety  analysis.  In  this  way,  the 
SSSTRP  continues  to  provide  valuable  oversight 
for  the  safety  of  the  warfighter  utilizing  modern, 
software-intensive  systems. 
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(FISTRP):  Duties,  Responsibilities,  and  Processes 


Introduction 

The  Navys  Fuze  and  Initiation  System  Tech¬ 
nical  Review  Panel  (FISTRP) — which  is  a  subpan¬ 
el  of  the  Navy’s  Weapon  System  Explosives  Safety 
Review  Board  (WSESRB) — reviews  the  designs  of 
fuzes  and  initiation  systems  to  assure  that  they  are 
safe  for  their  intended  use  in  munitions.  Fuzes  and 
initiation  systems  are  devices  that  control  the  safe¬ 
ty  of  the  munition  during  manufacture,  handling, 
logistic  deployment  and  use.  The  FISTRP  is  tasked 
with  reviewing  fuze  and  initiation  system  designs 
during  development  and  providing  an  assessment 
of  the  compliance  of  these  systems  with  safety  re¬ 
quirements;  FISTRP  is  a  vital  arm  of  the  Navy’s  in¬ 
dependent  safety  review  program. 

Purpose  and  Membership 

Technical  review  panels  (TRPs),  functioning 
as  subpanels  to  the  Navy’s  WSESRB,  were  imple¬ 
mented  in  the  early  1990s  to  add  a  focused  safe¬ 
ty  review  capability  to  the  overall  WSESRB  review 
function.  The  operational  processes  for  TRPs 
were  developed  by  the  WSESRB.  The  FISTRP  is 
one  of  these  regularly  meeting  subpanels  of  the 
WSESRB. 

The  purpose  of  the  FISTRP  is  to  provide  expert 
technical  safety  review  of  the  design  of  safety  and 
arming  devices/fuzes,  ignition  safety  devices,  and 
related  safety  devices  used  in  Navy  weapon  sys¬ 
tems.  The  FISTRP  reviews  system  designs  against 
established  Department  of  Defense  (DoD)  or  in¬ 
ternational  safety  design  requirements,  including 
North  Atlantic  Treaty  Organization  (NATO)  Stan¬ 
dardization  Agreements  (STANAGs)  and  U.S.  Mil¬ 
itary  Standards.  Safety  criteria  utilized  for  a  review 
by  the  FISTRP  include,  but  are  not  limited  to: 

NATO  STANAGs: 

•  4187— Fuzing  Systems  Safety  Design  Require¬ 
ments 

•  43 68— Electric  and  Laser  Ignition  Systems  for 
Rockets  and  Guided  Missile  Motors  Safety  De¬ 
sign  Requirements 

•  449 7— Hand-Emplaced  Munitions  (HEM), 
Principles  of  Safe  Design 

Military  Standards: 

•  131 6— Fuze  Design ,  Safety  Criteria  for 

•  1901— DoD  Design  Criteria  Standard ,  Muni¬ 
tion  Rocket  and  Missile  Motor  Administration 
System  Design  and 

•  1911—  Hand-Emplaced  Ordnance  Design, 
Safety  Criteria  for 

The  WSESRB  Technical  Manual  on  Electron¬ 
ic  Safety  and  Arming  Devices  with  N on-interrupted 
Explosive  Trains  is  also  used  as  a  resource  for  fol¬ 
lowing  safety  criteria. 


By  ensuring  adherence  to  the  principles  es¬ 
poused  in  these  guidelines,  the  FISTRP  is  able  to 
address  the  multitude  of  areas  where  safety  risk 
is  inherent  in  these  critical  systems.  For  example, 
STANAG  4187  provides  detailed  safety  design  cri¬ 
teria  for  warhead  safety  and  arming  devices  and 
fuzes.  A  FISTRP  review  results  in  an  assessment 
of  the  safety  design  and  recommendations  for  the 
program  and  the  WSESRB.  This  assessment  is  doc¬ 
umented  in  a  summary  report  and  includes  justifi¬ 
cations  for  the  recommendations  made. 

The  WSESRB  chairperson  designates  the 
chairperson  for  the  FISTRP.  The  remainder  of  the 
panel  is  composed  of  technical  experts  drawn  from 
a  variety  of  areas  across  the  Navy  and  can  include 
subject  matter  experts  from  other  services,  as  nec¬ 
essary.  In  addition,  due  to  the  multiservice  utiliza¬ 
tion  of  many  modern  munitions,  the  Navy  FISTRP 
often  acts  in  concert  with  other  services  to  hold 
joint  service  reviews.  The  FISTRP  interfaces  direct¬ 
ly  with  the  Army’s  Fuze  Safety  Review  Board  and 
members  of  the  U.S.  Air  Force’s  Nonnuclear  Safety 
Board  on  fuze  and  initiation  system  programs  of 
mutual  interest.  Members  are  selected  for  their  ex¬ 
pertise  in: 

•  Fuze  design 

•  Ignition  safety  device  design 

•  Explosives  safety 

•  Logic  systems 

•  System  safety 

•  Fuze  development 

•  Individual  weapon  systems  design  and  de¬ 
velopment 

Members  are  rotated,  as  required,  to  ensure 
that  they  do  not  have  conflicting  interests  in  the 
program  being  reviewed.  Members  of  the  FISTRP 
also  actively  participate  in  DoD’s  Fuze  Engineering 
Standardization  Working  Group  (FESWG),  which 
develops  and  maintains  fuze  and  initiation  safe¬ 
ty  design  requirements  for  DoD  and  keeps  the 
WSESRB  abreast  of  the  FESWG  activities. 

Scope 

The  scope  of  a  FISTRP  will  vary  depend¬ 
ing  upon  the  needs  of  the  program.  FISTRP  re¬ 
views  generally  fall  into  one  of  three  categories: 
a  full  FISTRP  meeting,  a  letter  data  package  re¬ 
view,  or  a  technical  assistance  meeting.  A  full  FIS¬ 
TRP  meeting  involves  a  formal  safety  review  of 
the  design  of  safety  and  arming  device/fuze,  igni¬ 
tion  safety  device,  or  related  safety  device,  and  re¬ 
quires  a  complete  technical  data  package  before 
the  FISTRP  will  be  scheduled.  The  program  then 
follows  with  an  in-person  presentation  to  the  pan¬ 
el.  FISTRP  recommendations  and  action  items  are 
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coordinated  with  and  documented  by  the  WSES- 
RB.  When  limited  or  narrowly  focused  issues  are 
in  question,  or  when  closing  out  previous  action 
items,  a  letter  data  package  review  may  be  suffi¬ 
cient  in  lieu  of  a  full  FISTRP  meeting.  In  this  in¬ 
stance,  the  program  representatives  do  not  need 
to  appear  before  the  panel  to  present  their  data; 
they  simply  provide  the  necessary  data  in  writing, 
accompanied  by  a  letter  explaining  their  purpose 
for  submission.  The  results  of  letter  data  package 
reviews  are  also  coordinated  with  and  document¬ 
ed  by  the  WSESRB.  Technical  Assistance,  or  Tech 
Assist,  meetings  are  informal  reviews  of  issues  or 
concepts  where  no  formal  recommendations  are 
provided  to  the  program.  These  are  provided  pri¬ 
marily  to  aid  the  program  in  addressing  specific 
issues  and  defining  a  way  forward. 

While  all  requirements  in  the  design  safety  area 
are  important  and  are  assessed  during  a  FISTRP  re¬ 
view,  the  following  areas  normally  receive  particu¬ 
lar  attention  during  a  FISTRP: 

•  Identification/description  of  independent 
safety  features  in  safety  devices,  complex 


logic  devices,  or  firmware  used  in  the  safe¬ 
ty  logic 

•  Cut  sets  and  numerical  analysis  associated 
with  fault  tree  analysis 

•  Safety  and  environmental  test  programs 

•  Qualification  of  explosive  devices 

The  Review  Process 

The  program  will  recommend  the  appropri¬ 
ate  level  of  review  and  coordinate  the  review  type 
and  review  date  with  the  FISTRP  chairperson  and 
the  appropriate  WSESRB  point  of  contact  (POC) 
for  the  program.  Typically,  FISTRPs  will  be  held 
15  to  30  days  in  advance  of  a  regularly  scheduled 
WSESRB.  The  Chairperson  of  the  FISTRP  is  re¬ 
sponsible  for  contacting  the  other  members  and 
making  arrangements  for  their  attendance.  The 
length  of  the  meetings  will  generally  be  1  day  or 
less.  A  typical  1-day  FISTRP  review  will  consist  of 
no  more  than  5  hours  of  review/discussions  with 
the  program  representatives  and  up  to  3  hours  for 
panel  members  to  caucus  and  draff  findings  and 
recommendations. 
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Lessons  Learned 

Over  time,  and  as  the  FISTRP  process  contin¬ 
ues  to  be  employed,  a  number  of  lessons  learned 
and  observations  arising  from  the  FISTRP  process 
are  worth  noting: 

Lesson  1:  Recent  acquisition  policy,  along  with 
technology  advancements,  has  resulted  in  a  widen¬ 
ing  of  initiation  safety  system  design  responsibili¬ 
ty.  Evolution  of  safety  design  requirements  can  be 
seen  in  the  requirements  for  in-line  ignition  sys¬ 
tems  for  safety  and  arming  devices  and  rocket  mo¬ 
tor  ignition  systems,  programmable  logic  devices, 
and  built-in  test  features.  These  factors  have  ex¬ 
panded  the  design  safety  requirements  and  their 
application— increasing  the  potential  for  unfamil¬ 
iarity  and  misunderstanding— and  have  resulted  in 
an  increased  need  for  design  safety  evaluation  pro¬ 
vided  by  forums  such  as  the  FISTRP. 

Lesson  2:  Design  safety  evaluations  early  in 
the  development  process  are  essential  to  arriv¬ 
ing  at  the  most  effective  design  approaches,  while 


U.S.  Navy  Fuze  and  Initiation  System  Technical  Review  Panel 
(FISTRP):  Duties,  Responsibilities,  and  Processes 


minimizing  the  impact  to  the  programs  involved. 
Unfortunately,  program  costs  and  schedules  have 
been  impacted  as  the  result  of  lack  of  compliance 
with  design  safety  requirements.  Technology  ad¬ 
vancements  also  impact  safety  design  criteria. 
This  is  particularly  true  in  the  rapidly  advancing 
capabilities  of  logic  devices  and  their  associated 
tools  and  implementation.  The  safety  communi¬ 
ty  is  examining  these  impacts  and  applying  les¬ 
sons  learned  to  the  existing  safety  design  criteria 
documents. 

Lesson  3:  Arming  decisions  for  military  muni¬ 
tions  are  generally,  though  not  always,  based  on  the 
existence  of  some  very  simple  conditions  and  en¬ 
vironments.  In  these  cases,  it  is  strongly  preferred 
that  the  complexity  of  the  safety  features  validat¬ 
ing  these  conditions  and  enabling  arming  be  min¬ 
imized  to  preclude  inadvertent  subversion  via 
unexpected  or  unrecognized  paths. 

Lesson  4:  Not  every  design  can  be  evaluated 
solely  by  analysis.  Comprehensive  test  plans  of¬ 
ten  expose  safety  and  reliability  issues  that  are  not 
caught  during  paper  evaluations. 

Lesson  5:  As  joint  efforts  increase  both  within 
DoD  and  within  NATO,  the  coordination  of  safety 
design  requirements  for  fuze  and  initiation  systems 
maybe  impacted.  Similarly,  as  technology  progress¬ 
es,  the  safety  requirements  tend  to  evolve  to  address 
issues  that  did  not  previously  exist.  Evidence  of  this 
can  be  seen  in  the  move  away  from  U.S.  Military 
Standards  to  STANAGs,  as  well  as  the  rapid  pro¬ 
gression  of  electronic  logic  devices  and  the  move¬ 
ment  to  all-electronic  safety  devices.  The  NATO 
and  DoD  communities  are  adapting  to  these  condi¬ 
tions  through  the  updating  of  design  safety  criteria. 

Summary 

The  FISTRP  provides  a  detailed  review  forum 
for  the  safety  design  aspects  of  fuze  and  initiation 
systems  in  support  of  the  WSESRB.  The  FISTRP  is 
tasked  with  reviewing  fuze  and  initiation  system 
designs  against  safety  design  criteria  established 
both  nationally  and  internationally  in  STANAGs 
and  U.S.  Military  Standards.  These  reviews  nor¬ 
mally  take  place  prior  to  major  milestone  decisions; 
however,  experience  has  shown  that  earlier  safety 
assessment  of  designs  is  the  most  effective.  The  FIS¬ 
TRP  membership  provides  a  broad  spectrum  of  ex¬ 
perience  and  expertise  during  the  review  process. 
This  includes  participation  of  U.S.  Army  and  Air 
Force  representatives  when  available  and  appropri¬ 
ate.  The  overall  goal  of  the  WSESRB  FISTRP  is  to 
enhance  the  safety  of  fuze  and  initiation  system  de¬ 
signs  via  an  independent  assessment  so  that  the  sys¬ 
tems  comply  with  applicable  safety  requirements. 
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By  Robert  Gmitter 


Background 

The  challenges  to  designing,  procuring,  and  fielding  safe  joint  service  weapon  and 
laser  systems  for  the  warfighter  include:  weapon/environment  interoperability,  service- 
unique  design  requirements,  service-unique  testing  requirements  and  processes,  and 
differences  in  services  safety  and  laser  review  processes.  There  has  been  no  single  joint 
service  safety  review  board  or  authority  to  address  these  challenges  in  a  coordinated 
manner.  Weapon  system  and  laser  safety  releases,  approvals,  or  certifications  were  re¬ 
quired  from  each  of  the  multiple  service  safety  review  boards  as  shown  in  Figure  1.  Each 
of  these  individual  service  safety  review  boards  utilizes  unique  processes  designed  to 
meet  their  specific  requirements.  The  downside  of  these  service-unique  reviews  for  pro¬ 
gram  managers  (PMs)  is  that  it  is  often  expensive,  redundant,  and  time-consuming;  it 
also  has  the  potential  to  result  in  conflicting  safety  requirements  or  actions. 

This  is  an  inherent  problem  for  United  States  Special  Operations  Command  (USSO- 
COM)  weapon  and  laser  system  acquisition  programs  since  USSOCOM  is  composed  of 
elements  from  all  four  branches  of  the  U.S.  armed  forces  (see  Figure  2).  The  USSOCOM 
Acquisition  Executive  determined,  therefore,  that  all  weapons,  munitions,  ordnance,  la¬ 
ser  systems,  or  related  devices  developed  or  procured  for  USSOCOM  use  would  be  con¬ 
sidered  joint  use  systems  since  they  would  be  available  for  use  by  all  service  components 
of  USSOCOM. 

USSOCOM  Joint  Weapon  Safety  Review  Process 

In  July  2005,  as  the  result  of  a  request  from  USSOCOM,  the  Defense  Safety  Over¬ 
sight  Council  (DSOC)  Acquisition  and  Technology  Programs  (ATP)  Task  Force  (TF) 
chartered  a  Joint  Weapon  Safety  Working  Group  (JWSWG)  to  begin  developing  a  col¬ 
laborative  joint  service  safety  review  process  for  USSOCOM  weapon,  ordnance,  and  la¬ 
ser  systems  in  order  to  eliminate  the  inefficiencies  inherent  in  the  safety  review  process. 
The  JWSWG  consisted  of  safety  and  laser  experts  from  USSOCOM,  the  Army,  the  Navy, 
the  Marine  Corps,  the  Air  Force,  the  Department  of  Defense  Explosives  Safety  Board 
(DDESB),  and  the  Office  of  the  Under  Secretary  of  Defense  (OUSD)  for  Acquisition, 
Technology,  and  Logistics  (AT&L).  The  JWSWG  used,  and  is  continuing  to  use,  the  fol¬ 
lowing  approach  to  develop  the  collaborative  USSOCOM  Joint  Safety  Review  Process: 

•  Requests  candidate  USSOCOM  programs  to  validate  the  process 

•  Modifies  the  process  as  necessary 
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Existing  Services’  Weapon  Safety  Review  Boards, 
Organizations,  and  Processes 

S’  •  Material  Release  Process 

•  Army  Fuze  Safety  Review  Board 

•  Ignition  System  Safety  Review  Board 

•  Center  for  Health  Promotion  &  Preventive  Medicine  (Lasers) 

•  System  Safety  Division,  Army  Armament  Research, 
Development,  and  Engineering  Center 

V_  *  Safety  Division,  Army  Aviation  and  Missile  Command 


•  Weapon  System  Explosives  Safety  Review  Board 

-Systems  Software  Safety  Technical  Review  Panel 

-Fuze  and  Initiation  System  Technical  Review  Panel 

•  Lithium  Battery  Safety  Review  Process 

•  Laser  Safety  Review  Board 


*  Nonnuclear  Munitions  Safety  Board 

•  Laser  System  Safety  Review  Board 


Figure  1.  List  of  U.S.  Services’  Safety  Review  Boards  and  Organizations 


SPECIAL  FORCES 
RANGERS 
AVIATION 
PSYOP 

CIVIL  AFFAIRS 


SEAL  TEAMS 
SPECIAL  BOAT  TEAMS 
SEAL  DELIVERY 
VEHICLE  TEAMS 


SPECIAL  OPERATIONS 
REGIMENT 
FOREIGN  MILITARY 
TRAINING  UNIT 
SPECOPS  SUPPORT 
GROUP 


AVIATION 

-  FIXED  WING 

-  ROTARY  WING 
SPECIAL  TACTICS 
COMBAT  WEATHER 


JOINT  STANDING 
BATTLESTAFFS 
AND  C41  STRUCTURE 


Figure  2.  USSOCOM  Organizations 
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•  Proceeds  with  full  implementation 

•  Continues  modifications  to  process,  based 
on  lessons  learned 

The  USSOCOM  Joint  Safety  Review  Process  is 
shown  in  Figure  3  and  is  designed  to  deliver  safe 
weapon  systems  to  the  USSOCOM  warfighter 
through  the  coordinated  and  collaborative  efforts 
of  the  individual  services  safety  review  authorities. 
Classified  joint  safety  reviews  are  currently  not 
part  of  this  process. 

The  USSOCOM  Joint  Weapon  Safety  Review 
process  consists  of  seven  main  elements: 

1.  Collaborative  planning  &  consolidation  of 
requirements 

2.  Adjudication  of  requirements  (if  necessary) 

3.  Execution  of  testing  and  analysis  for  sys¬ 
tem/product 

4.  Collaborative  reviews  of  testing  and  analy¬ 
sis  results 

5.  Adjudication  of  results  (if  necessary) 


6.  Identification  and  documentation  of  resid¬ 
ual  risks  (if  necessary) 

7.  Acquisition  community  acceptance  of  re¬ 
sidual  risk(s).  User  representative  must  pro¬ 
vide  formal  concurrence  prior  to  all  high 
and  serious  risk  acceptance  decisions. 

There  are  three  major  participants  in  the 
USSOCOM  Joint  Weapon  Safety  Review  Process: 
System  Safety  Lead  (SSL),  Service  Safety  Review 
Coordinator  (SSRC),  and  the  Lead  Service  Safety 
Review  Coordinator  (LSSRC). 

The  SSL  is  the  acquisition  PM’s  system  safety 
representative  and  is  usually  the  Principal  For  Safe¬ 
ty  (PFS)  for  U.S.  Navy  and  Marine  Corps  programs. 
The  SSLs  responsibilities  include  leading  the  Safe¬ 
ty  Integrated  Product  Team  (IPT)  or  System  Safe¬ 
ty  Working  Group  (SSWG),  as  well  as  executing 
the  System  Safety  Program  (SSP)  and  System  Safe¬ 
ty  Program  Plan  (SSPP).  The  SSL  is  appointed  by 
the  acquisition  PM. 


PM/SSL  coordinates  with  respective 
SSRCs  to  identify  all  participating  safety 
organizations  and  boards 


PM/SSL,  in  coordination  with  SSRCs,  develops 
the  joint  safety  requirements  and  safety 
review  process,  including  review  timeline  and 
resource  requirements. 


Joint 

Service  Safety 
Agreement,  with  identified 
limitations,  if 


Execute  Program  with  any  restriction 
and/or  limitation  resulting  from  the 
risk  identification,  mitigation,  and 
acceptance  process 


Conduct  collaborative  joint  safety 
reviews  at  appropriate  milestones 
and  provide  consolidated  findings 
and  coordinated  approvals  and/or 
certifications 


SSRC  =  Service  Safety  Review  Coordinator 
SSL  -  System  Safety  Lead,  includes 

Principal  for  Safety  (PFS),  system 
safety  engineers 

EC  =  Executive  council  includes  Chair/Vice 
Chain  from  services’  existing  boards 
&  Chiefs  of  Safety/System  Safety 


Figure  3.  Joint  Weapon  Safety  Review  Process 
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Each  SSRC  is  selected  by  a  services  safety  re¬ 
view  authority  or  USSOCOM.  The  SSRC  serves  as 
the  primary  point  of  contact  to  assist  the  SSL  and 
work  with  the  LSSRC  to  help  facilitate  collabora¬ 
tive  joint  safety  reviews  of  USSOCOM  weapon  sys¬ 
tems,  ordnance,  and  laser  systems.  An  SSRC  may 
designate  a  technical  representative  to  assist  and 
serve  as  the  SSRC  s  technical  POC. 

The  acquiring  service  or  USSOCOM  provides 
the  LSSRC,  who  coordinates  with  the  other  SSRCs 
and  the  SSL  for: 

•  Safety  technical  data  package  (TDP)  content 

•  Joint  review  of  the  TDP 

•  Conduct  of  the  Joint  Boards  review,  if  re¬ 
quired 

•  Drafting  of  letter  and  coordinating  final  sig¬ 
natures 

•  Monitoring  closure  of  Joint  Boards  findings 

•  Drafting  and  coordinating  signatures  on  fi¬ 
nal  letter  from  the  joint  services  safety 
organizations  providing  safety  verification 
to  support  fielding/operational  use 

The  leadership  role  in  the  USSOCOM  Joint 
Weapon  Safety  Review  Process  is  provided  by 


the  Executive  Council  (EC),  which  comprises 
the  Chair/Vice  Chair  from  the  existing  individ¬ 
ual  weapon  system  safety  boards  and  the  desig¬ 
nated  US.  Army  Chiefs  of  Safety/System  Safety. 
The  purpose  of  the  EC  is  to  resolve  disparities 
among  the  services  regarding  weapon  safety  re¬ 
quirements  and  findings  from  the  boards.  The 
EC  does  not  resolve  laser  safety  requirements  or 
findings. 

USSOCOM  Joint  Laser  Safety 
review  Process 

Similar  to  the  USSOCOM  Joint  Safety  Review 
Process  depicted  in  Figure  3  is  the  USSOCOM  Joint 
Laser  System  Safety  Review  Process.  This  process, 
shown  in  Figure  4,  was  designed  to  deliver  safe  la¬ 
ser  systems  to  the  USSOCOM  warfighter  through 
the  coordinated  and  collaborative  efforts  of  the  in¬ 
dividual  services  laser  safety  authorities. 

There  are  two  major  participants  in  the 
USSOCOM  Joint  Laser  System  Safety  Review  Pro¬ 
cess:  the  Service  Laser  Safety  Review  Coordinator 
(SLSRC)  and  the  Lead  Service  Laser  Safety  Review 
Coordinator  (LSLSRC). 


PM  /  SSL  engages  LSLSRC 


LSLSRC  coordinates  with  Air  Force  and  Navy 
LSSRBs  and  Army  L/ORP  to  define  the  level  of 
review,  schedule,  and  resources,  and  provides 
information  to  the  PM  /  SSL 


PM  forwards  laser 
data  packages  to 
LSLSRC 


Services  complete 
joint  technical 
assessment 


LSLSRC  forwards 
technical  assessment 
report(s)  and  data 
packages  to  SLSRAs  for 


Navy/Marine  Corps  &  Air 
Force  LSSRB  Chairs  and 
PM  L/ORP  submit  findings 
of  safety  evaluation  to  lead 
SLSRA 


Laser  Safety  Adjudication  Process 

l 


Yes 


PM  coordinates  with  lead 
SLSRA  to  find  possible 
alternate  actions  for 
mitigation  of  all  safety 
deficiencies  /  issues 


Yes 


Lead  SLSRA  provides 
consolidated  deficiency 
letter  to  USSOCOM  PM  for 
action 


Lead  SLSRA  provides  joint 
service  safety  approval 
letter  to  PM  (cc:  Navy/Marine 
Corps  &  Air  Force  LSSRBs 
and  L/ORP) 


No 


CAE  /  PEO  /  PM  decision  to 
accept  risk  for  any  remaining 
deficiencies,  per  DoD  5000.2 


Execute  program  (System  Design, 
Development,  or  COTS  /  NDI 
Selection)  or  conduct  other  safety 
reviews  IAW  with  Joint  Safety 
Review  Process,  per  Figure  3 


COTS  =  Commercial  Off-the-Shelf 
L/ORP  =  Laser/Optical  Radiation  Program  (Army) 
LSLSRC  =  Lead  Service  Laser  Safety  Review  Coordinator 
LSSRB  =  Laser  System  Safety  Review  Board 
NDI  =  Nondevelopmental  Item 
SLSRA  =  Service  Laser  Safety  Review  Authority;  i.e., 
Chair  Navy  LSRB;  Chair,  Air  Force  LSSRB; 
and  Manager,  L/ORP 
SSL  =  System  Safety  Lead 
SSRC  =  Service  Safety  Review  Coordinator 


Figure  4.  Joint  Laser  Safety  Review  Process 
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The  SLSRC  is  the  point  of  contact  identified  by 
a  service  to  be  the  initial  lead  for  coordinating  the 
review  of  a  laser  system.  The  SLSRC  can  be  from 
the  Air  Force  Laser  System  Safety  Review  Board 
(LSSRB),  the  Navy  Laser  Safety  Review  Board 
(LSRB),  or  the  U.S.  Army  Center  for  Health  Pro¬ 
motion  and  Preventative  Medicine  (USACHPPM) 
Laser/Optical  Radiation  Program  (L/ORP). 

The  service  assigned  the  lead  for  the  acquisi¬ 
tion  effort  will  provide  the  LSLSRC.  The  LSLSRC 
coordinates  with  the  other  SLSRCs  and  the  SSL  for: 

•  Laser  safety  TDP  content 

•  Joint  laser  safety  review  of  the  TDP 

•  Conduct  of  the  joint  laser  safety  review,  if 
required 

•  Drafting  of  letter  and  coordination  of  final 
signatures 

•  Monitoring  closure  of  joint  laser  safety 
findings 

•  Drafting  and  coordination  of  signatures  on 
final  letter 

For  laser  systems,  if  any  service  has  identified 
a  laser  safety  deficiency,  this  system  cannot  be  ap¬ 
proved  for  joint  service  use  until  all  deficiencies  are 
satisfactorily  resolved  by  the  PM  and  SLSRAs. 


USSOCOM  Joint  Weapon  Safety 
and  Laser  Safety  review  Summary 

fhe  Office  of  the  Secretary  of  Defense  (OSD) 
joint  weapon  and  laser  safety  guide,  Joint  Systems 
Safety  Review  Guide  for  USSOCOM  Programs ,  Ver¬ 
sion  1.1,  dated  12  October  2007,  provides  contact 
information  for  SSRCs  and  SLSRCs,  along  with 
guidance  on  review  criteria  expectations  for  TDP 
submissions  in  support  of  weapon  and  laser  safety 
reviews.  The  Service  Acquisition  Executives  signed 
the  Memorandum  of  Agreement  implementing  the 
USSOCOM  Joint  Weapon  Safety  and  Laser  Safe¬ 
ty  Review  Processes  in  October  2007.  More  than 
15  acquisition  programs  are  presently  in,  or  have 
completed,  the  USSOCOM  Joint  Weapon  Safe¬ 
ty  and  Laser  Safety  Review  Process  as  part  of  their 
validation.  While  no  cost  or  time-savings  metrics 
have  been  compiled  to  date,  anecdotal  data  indi¬ 
cates  significant  savings  are  being  realized  for  US¬ 
SOCOM  programs  via  this  process. 

DEPARTMENT  OF  DEFENSE  (DOD) 
JOINT  SERVICE  WEAPON  AND  LASER 

Safety  Review  Process 

The  DSOC  ATP  TF  tasked  the  JWSWG  to  ex¬ 
pand  the  USSOCOM  joint  weapon  and  laser  safety 
review  processes  to  include  all  DoD  joint  weap¬ 
on  and  laser  system  acquisitions  and  fielding  deci¬ 
sions.  The  JWSWG  is  using  the  same  collaborative 
approach  as  that  used  for  the  USSOCOM  Joint 
Safety  Review  Process.  The  DoD  Joint  Weapon  and 
Laser  Safety  Review  Process  consists  of  the  same 
seven  main  elements  as  the  USSOCOM  process; 
therefore,  the  process  charts  in  Figures  3  and  4  still 
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apply.  Also,  the  weapon  and  laser  safety  process 
participant  (i.e.,  SSL,  SSRC,  SLSRC,  etc.)  descrip¬ 
tions  and  responsibilities  still  apply.  The  JWSWG  is 
developing  a  new  DoD  Instruction  implementing 
the  Joint  Service  Weapon  Safety  Review  (JSWSR) 
Guide  that  will  closely  resemble  the  Joint  Systems 
Safety  Review  Guide  for  USSOCOM  Programs. 

The  JSWSR  process  is  facilitated  by  a  joint 
meeting  of  the  services  safety  review  authorities 
or  Army’s  designated  Chief  of  Safety/ System  Safe¬ 
ty.  Such  joint  meetings  are  referred  to  as  a  “meet¬ 
ing  of  the  Joint  Boards”  or  “Joint  Boards”  and  are 
co-chaired  by  the  Chairpersons  or  Vice  Chairper¬ 
sons  from  the  service  boards  in  attendance  and  by 
the  Chief  of  Safety  from  the  appropriate  Army  ma¬ 
jor  command.  The  Chairperson  or  Chief  of  Safety 
from  the  service  that  is  lead  for  the  weapon  acqui¬ 
sition  effort  hosts  meetings  of  the  Joint  Boards. 

A  written  statement  by  the  Joint  Boards  verify¬ 
ing  that  the  weapon  or  laser  system  provides  ade¬ 
quate  design  safety  and  meets  each  services  safety 
requirements  will  constitute  a  Joint  Weapon  Safe¬ 
ty  Certification.  If  the  weapon  system  fails  to  meet 
any  of  the  services’  safety  requirements,  the  state¬ 
ment  will  verify  that  the  weapon  system  PM  has  ac¬ 
curately  identified  the  risk  of  this  noncompliance 
or  has  accepted  the  risk  at  the  appropriate  level,  per 
DoDI  5000.2,  Operation  of  the  Defense  Acquisition 
System.  The  JSWSR  process  has  been  validated  on 
numerous  occasions,  including  twice  for  the  joint 
Mine  Resistant  Ambush  Protected  (MRAP)  Vehi¬ 
cle  Program. 


SUMMARY 

In  the  past,  there  has  been  no  single,  joint 
service  safety  review  board  or  authority  for 
USSOCOM  programs  that  are  joint  by  nature. 
Weapon  system  and  laser  safety  releases,  approv¬ 
als,  or  certifications  were  required  from  each  of 
the  unique  service  safety  review  boards,  with  the 
potential  programmatic  downside  of  added  ex¬ 
pense,  redundancy,  schedule  slippage,  and  con¬ 
flicting  safety  requirements  or  actions. 

The  joint  weapon  and  laser  safety  review  pro¬ 
cesses  in  support  of  USSOCOM  are  now  finalized 
and  documented  in  an  OSD  guide  titled,  Joint  Sys¬ 
tems  Safety  Review  Guide  for  USSOCOM  Programs , 
Version  1.1,  dated  12  October  2007.  More  than 
15  acquisition  programs  are  presently  in,  or  have 
completed,  the  USSOCOM  Joint  Weapon  Safety 
and  Laser  Safety  Review  Process. 

The  DoD  Joint  Weapon  and  Laser  Safety  Re¬ 
view  process  consists  of  the  same  seven  main  ele¬ 
ments  as  the  USSOCOM  process  but  will  apply  to 
non-USSOCOM  Joint  programs.  A  new  DoD  in¬ 
struction  implementing  the  JSWSR  Guide  that  will 
closely  resemble  the  Joint  Systems  Safety  Review 
Guide  for  USSOCOM  Programs  is  currently  being 
developed  and  validated. 
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United  States  Special  Operations 
Command  System  Safety 

By  Cathi  Crabtree 


Introduction 

Acquisition  system  safety  for  United  States  Special  Operations 
Command  (USSOCOM)  is  the  practice  of  controlling  system  and 
technical  hazards  throughout  the  system  life  cycle.  Through  the 
process  of  first  identifying  and  then  mitigating  or  eliminating  haz¬ 
ards  early  in  the  system  design  process,  the  overall  system  perfor¬ 
mance  can  be  optimized.  This  practice  is  one  of  the  key  elements  of 
the  systems  engineering  discipline  and  methodology.  It  integrates 
hazard  identification  with  the  associated  hazard  management  and 
mitigation  for  the  system  within  the  constraints  of  the  program. 
The  objective  is  to  design  out  risks  early  in  the  acquisition  process 
so  that  an  item  or  system,  by  virtue  of  its  design  or  safety- specif¬ 
ic  design  features,  prevents  or  minimizes  safety-related  problems 
throughout  its  life  cycle. 

This  general  description  should  sound  pretty  familiar  to  most 
who  deal  with  system  safety.  Where  USSOCOM  begins  to  diverge 
from  much  of  the  Department  of  Defense  can  be  summed  up  in 
the  following  statement: 

Special  Operations-peculiar  systems  shall  always  be  de¬ 
signed  and  evaluated  for  safety  of  use,  handling,  storage,  and 
transportation  in  the  joint  warfighting  environment. 

Because  Special  Operations  Forces  (SOF)  comprise  compo¬ 
nents  from  each  service,  work  side-by-side  with  regular  forces 
from  each  service,  and  have  their  gear  transported  by  elements  of 
each  service,  it  is  essential  that  their  weapons,  munitions,  and  la¬ 
sers  meet  the  safety  requirements  of  all  services. 
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Background 

In  October  2007,  the  USSOCOM  Acquisition 
Executive  designated  all  USSOCOM  acquisition 
programs  as  joint  use,  and  the  Department  of  De¬ 
fense  established  the  Joint  Systems  Safety  Review 
Process  for  USSOCOM  programs.  This  process 
was  developed  to  prevent  the  consecutive  process¬ 
ing  of  USSOCOM  weapons,  munitions,  and  lasers 
through  the  various  services  safety  processes;  in¬ 
stead,  the  processes  start  at  once  so  they  can  con¬ 
currently  proceed;  see  Figure  1. 

Key  to  the  success  of  this  joint  review  is  the  in¬ 
volvement  of  the  Service  Safety  Review  Coordi¬ 
nators  (SSRCs),  the  gatekeepers  to  each  services 
system  safety  process.  These  SSRCs  (one  per  ser¬ 
vice)  collaborate  throughout  the  concurrent  review 
process  to  ensure  that  the  program  manager  (PM) 
and  the  System  Safety  Lead  do  not  become  dispa¬ 
rate  and  to  avoid  the  possibility  of  conflicting  guid¬ 
ance  on  their  system  safety  program. 

Numerous  weapons,  munitions,  and  laser  sys¬ 
tems  are  working  through  the  joint  process,  and 
there  have  been  challenges.  However,  new  insight 
is  being  gained  daily,  and  the  process  is  working 
more  smoothly  and  more  quickly  than  at  its  imple¬ 
mentation. 

Way  Ahead 

Now  that  the  process  has  been  in  existence  for 
approximately  2  years,  lessons  learned  are  being 
reviewed,  and  input  is  being  gathered  from  the 
various  stakeholders  including,  but  not  limited 
to,  the  logistics  community,  the  safety  communi¬ 
ty,  the  technology  and  engineering  (T&E)  com¬ 
munity,  and  the  PM  community. 

The  complete  Joint  Systems  Safety  Review 
Guide  for  USSOCOM  programs  and  the  Mem¬ 
orandum  of  Agreement  implementing  it  can  be 
found  at  the  Acquisition  and  Technology  Programs 
Task  Force  (ATP  TF)  Web  site  at  http://www.acq. 
osd.mil/atptf/ 


Coordinators 


Service  Safety  Review  Coordinator  (SSRC) 


Service  Laser  Safety  Review  Coordinator  (SLSRC) 


Army 

Materiel  Release  Boards 

Safety  Review  Board 

Ignition  System  Safety  Review  Board 


Air  Force 

Nonnuclear  Munitions  Safety  Board 
Laser  System  Safety  Review  Board 


Other  membership  as  necessary 

SME,  T&E 


Figure  1.  Joint  Service  Coordination 
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Types  of  System  Safety  Efforts 

Introduction 

The  term  ordnance  is  defined  as  military  materiel,  including  combat  weapons  of  all 
kinds,  with  ammunition  and  explosives  (A&E),  and  equipment  required  for  their  use. 
Ordnance  includes  all  the  things  that  make  up  a  ships  or  aircrafts  armament;  i.e.,  guns, 
A&E,  and  all  equipment  needed  to  control,  operate,  and  support  the  weapons.  This  arti¬ 
cle  discusses  the  necessity  and  methodology  for  performing  safety  analysis  to  ensure  that 
the  explosive  components  in  the  ordnance  we  provide  to  the  warfighter  fulfills  their  in¬ 
tended  purpose,  while  maintaining  a  margin  of  safety  for  the  users  and  noncombatants. 

It  is  the  nature  of  weapons  that  they  are  inherently  dangerous.  They  are,  after  all, 
designed  to  destroy  personnel,  equipment,  and  infrastructure.  Central  to  this  purpose 
is  the  presence  of  an  energetic  component,  for  which  safety  must  be  a  primary  consid¬ 
eration.  While  not  all  weapon  systems  contain  explosives,  such  as  electromagnetic  or 
directed  energy-based  systems,  most  modern  weapons  still  contain  some  explosive  ele¬ 
ment  either  in  a  warhead,  a  propulsion  system,  or  both.  While  the  former  are  still  dan¬ 
gerous  systems  for  which  safety  review  is  necessary,  it  is  to  the  latter — and  specifically, 
to  the  explosive  component  therein— that  our  attention  is  directed  in  this  discussion. 

The  weapons  discussed  above  that  contain  explosives  are  part  of  a  larger  system 
that  combines  the  mechanical,  electrical,  and  computational  components  to  effective¬ 
ly  launch  the  weapon  safely,  in  the  right  direction,  and  at  the  right  time.  Regardless  of 
whether  the  weapon  is  employed  from  land,  ship,  or  aircraft,  it  must  be  noted  that  safe¬ 
ty  of  explosives  is  typically  only  part  of  the  overall  safety  effort,  and  that  issues  regard¬ 
ing  safe  employment  are  bigger  than  the  safety  issues  of  just  the  explosive  components. 
A  complete  and  effective  system  safety  program  is  essential  to  protect  Navy  and  Marine 
Corps  assets,  and  to  maintain  a  warfighting  capability.  Note  that  a  “system”  in  this  con¬ 
text  can  vary  from  a  Sailor  manning  a  25mm  gun  providing  force  protection,  to  the  au¬ 
tomated  Aegis  system  with  sensors  to  monitor  positions  of  ships  and  aircraft,  computers 
to  track  and  identify  targets,  missile  launchers  and  gun  systems  to  engage  targets,  and 
personnel  to  operate  the  whole  system. 
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Why  is  Ordnance  Dangerous? 

The  successful  use  of  most  munitions  depends 
on  the  controlled  and  predictable  release  of  stored 
chemical  energy.  Substances  and  mixtures  of  sub¬ 
stances  that  are  employed  for  their  energetic  prop¬ 
erties  can  be  found  in  the  explosives  in  warheads, 
propellants,  and  a  variety  of  devices  that  use  pro¬ 
pellants  or  pyrotechnic  materials  to  generate  gas, 
heat,  light,  or  smoke.  The  rate  at  which  the  ener¬ 
gy  is  released  in  the  chemical  reactions  that  are 
characteristic  of  the  material  and  the  nature  of  the 
products  that  are  generated  in  the  reactions  deter¬ 
mine  the  applications  for  which  any  given  energet¬ 
ic  material  will  be  suitable. 

Although  the  overriding  concern  in  the  selec¬ 
tion  of  an  energetic  material  is  whether  it  will  per¬ 
form  adequately  for  the  application  of  interest,  the 
underlying  question  of  safety  is  always  present  and 
needs  to  be  factored  into  the  decision-making  pro¬ 
cess.  The  history  of  explosives  use  has  demonstrat¬ 
ed  repeatedly  that  mishaps  can  and  do  happen,  and 
that  the  consequences  of  accidents  involving  ex¬ 
plosives  can  be  catastrophic.  Therefore,  the  charac¬ 
terization  of  an  energetic  material  for  military  use 
must  involve  not  only  a  determination  of  its  ener¬ 
gy  output  under  the  conditions  of  intended  use  but 
also  its  response  to  unplanned  stimuli.  The  regula¬ 
tions  governing  the  qualification  of  explosives  for 


military  use  prescribe  tests  that  determine  the  sen¬ 
sitivity  of  energetic  materials  to  such  stimuli  as  im¬ 
pact,  friction,  electrostatic  discharge,  shock,  and 
heat.  These  tests  are  intended  to  simulate  the  haz¬ 
ards  to  which  an  explosive  might  be  exposed  dur¬ 
ing  storage,  transportation,  and  handling,  as  well 
as  during  hostile  action.  Additionally,  recent  de¬ 
velopments  in  warheads  technology  are  now  pre¬ 
senting  scenarios  in  which  explosives  must  survive 
very  harsh  environments  in  the  normal  course  of 
their  functioning.  The  best  known  case  of  this  type 
is  probably  hard  target  penetration,  wherein  the 
explosive  must  survive  the  stress  of  penetrating  a 
hardened  target  and  still  be  able  to  function  on  de¬ 
mand  in  the  interior  of  the  target. 

Nature  of  Energetics 

Explosives  safety  is  the  element  of  system  safe¬ 
ty  practiced  to  prevent  premature,  unintentional, 
or  unauthorized  initiation  of  explosives  and  devic¬ 
es  containing  explosives,  and  to  minimize  the  ef¬ 
fects  of  explosions,  combustion,  toxicity,  and  any 
other  deleterious  effects.  Explosives  safety  includes 
all  mechanical,  chemical,  biological,  electrical,  and 
environmental  hazards  associated  with  explosives 
or  electromagnetic  environmental  effects.  Equip¬ 
ment,  systems,  or  procedures  and  processes  whose 
malfunction  would  cause  unacceptable  mishap 
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risk  to  manufacturing,  handling,  transportation, 
maintenance,  storage,  testing,  delivery,  or  disposal 
of  explosives  are  also  included. 

Explosives  Safety  Program  Goals 

All  acquisition  programs  that  include  or 
support  A&E  items  must  comply  with  the  De¬ 
partment  of  Defense  (DoD)  explosives  safety  re¬ 
quirements.  The  program  manager  (PM)  for  a 
Navy  or  Marine  Corps  system  is  responsible  for 
implementing  a  safety  program  that  covers  all  as¬ 
pects  of  explosives  safety  and  meets  all  Depart¬ 
ment  of  the  Navy  (DON)  explosives  safety  policies 
and  requirements,  as  well  as  federal,  state,  and  lo¬ 
cal  regulations.  The  PM  is  responsible  for  design 
requirements,  management,  engineering,  and 
hazard  controls  for  conventional  A&E,  and  con¬ 
ventional  components  of  nonnuclear  weapons  sys¬ 
tems,  such  as  warheads,  rocket  motors,  separation 
charges,  igniters,  and  initiators.  A  complete  explo¬ 
sives  safety  program  for  A&E  items  requires  an 
integrated  effort  involving  several  different  disci¬ 
plines,  as  well  as  application  of  independent  over¬ 
sight.  For  the  Navy,  this  oversight  is  provided  by 
the  Weapon  System  Explosives  Safety  Review 
Board  (WSESRB)  and  the  Naval  Ordnance  Safety 
and  Security  Activity  (NOSSA). 

As  a  minimum,  an  explosives  safety  program 
should  provide  for  identifying  and  assessing  haz¬ 
ards  inherent  to  the  explosive  item  and  operations 
associated  with  it.  To  that  end,  the  program  should 
focus  on  the  following: 

•  Assurance  of  compliance  with  all  explosives 
policies,  procedures,  standards,  regulations, 
and  laws 

•  Assessment  of  system  designs  incorporating 
explosives  for  hazards  and  mishap  risk 

•  Application  of  design  mitigation  measures  to 
reduce  mishap  risk  to  an  acceptable  level 

•  Review  of  the  design  and  design  mishap  risk 
by  appropriate  safety  review  boards 

•  Documentation,  communication,  and  ac¬ 
ceptance  of  residual  system  mishap  risks 

•  Establishment  of  Explosives  Safety  Quanti¬ 
ty-Distance  (ESQD)  requirements  for  stor¬ 
age  of  A&E 

•  Facility  site  approvals  for  storage  of  A&E 

•  Explosives  hazard  classifications  for  trans¬ 
portation  of  A&E 

•  A  Hazards  of  Electromagnetic  Radiation  to 
Ordnance  (HERO)  program 

•  An  Insensitive  Munitions  (IM)  assessment 
and  test  program 

•  A  fuze  safety  program  to  ensure  compliance 
with  fuze  design  guidelines  and  standards 


Typical  Explosive  Ordnance 
Safety  Program 

An  explosive  ordnance  safety  program  follows 
a  prevention-focused  process  based  on: 

•  Reducing  the  probability  of  an  explosives 
mishap  from  occurring 

•  Reducing  the  consequences  of  an  explosives 
mishap,  should  it  occur 

•  Continually  informing  and  educating  per¬ 
sonnel  on  explosives  mishap  risks 

There  are  many  elements  to  an  explosive  ord¬ 
nance  safety  program.  Explosives  safety  is  a  joint 
effort  involving  many  disciplines,  such  as  weap¬ 
on  design,  fuze  design,  explosives  design,  test¬ 
ing,  IM  safety,  environmental  safety,  and  system 
safety.  For  this  reason,  it  is  difficult  to  explicit¬ 
ly  identify  all  tasks  related  to  an  explosives  safe¬ 
ty  effort. 

Appropriate  MIL-STD-882 
Hazard  Analyses 

Many  contracts  for  development  of  a  weapon 
system  within  the  Navy  or  Marine  Corps  have  only 
vague  discussion  of  the  need  and  extent  of  a  sys¬ 
tem  safety  program.  Often,  they  specify  that  the 
program  initiate  a  system  safety  program  in  accor¬ 
dance  with  MIL-STD-882,  with  no  other  guidance. 
Although  there  may  sometimes  be  references  to 
some  specific  area  of  the  discipline,  such  as  electri¬ 
cal  safety  requirements  or  human  factors  consid¬ 
erations,  the  rigor  of  the  system  safety  program  is 
often  left  up  to  the  system  design  agent  (DA).  DAs 
have  a  responsibility  to  develop  a  safe  system  but 
have  no  responsibility  to  deliver  documentation  of 
this  safety  program  to  the  government  unless  re¬ 
quired  under  the  contract.  Without  this  documen¬ 
tation  and  frequent  interaction  with  the  contractor 
during  conduct  of  the  system  safety  program,  the 
government  program  office  and  the  WSESRB  have 
no  basis  for  judging  the  overall  safety  of  the  weap¬ 
on  system.  If  we  can  assume  that  the  proper  lev¬ 
el  of  documentation  of  the  system  safety  program 
has  been  requested  in  the  weapon  system  develop¬ 
ment  contract,  what  then  constitutes  a  good  sys¬ 
tems  safety  program  for  a  Navy  or  Marine  Corps 
weapon  system? 

A  variety  of  sources  discuss  the  nature  of  a 
system  safety  program:  Naval  Sea  Systems  Com¬ 
mand  (NAVSEA)  SW020-AH-SAF-010,  Weapon 
System  Safety  Guidelines  Handbook  (Formerly  OD 
44942);  MIL-STD-882D,  Standard  Practice  for  Sys¬ 
tem  Safety ;  and  the  System  Safety  Society  Handbook 
are  some  examples  that  speak  in  terms  of  six  basic 
system  safety  hazard  analyses  that  should  be  per¬ 
formed  for  every  program.  These  are: 
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1.  Preliminary  Hazard  List  (PHL) 

2.  Preliminary  Hazard  Analysis  (PHA) 

3.  Safety  Requirements/Criteria  Analysis 
(SR/CA) 

4.  Subsystem  Hazard  Analysis  (SSHA) 

5.  System  Hazard  Analysis  (SHA) 

6.  Operating  and  Support  Hazard  Analysis 
(O&SHA) 

When  safety  is  involved  from  the  beginning 
of  a  program,  each  of  these  analyses  provides  spe¬ 
cific  benefits.  However  its  sometimes  the  case  that 
safety  becomes  involved  later  in  the  program.  In 
these  instances,  the  safety  engineer  must  make  val¬ 
ue  judgments  on  the  utility  of  the  various  analy¬ 
ses,  depending  on  the  extent  to  which  he/she  feels 
the  design  can  reasonably  be  affected  should  a  safe¬ 
ty  risk  be  identified.  If  the  design  has  been  frozen, 
it  makes  sense  to  tailor  the  safety  effort  to  focus  ef¬ 
forts  on  identifying  hazards  for  which  mitigations 
that  do  not  entail  design  changes  are  appropriate. 
In  the  performance  of  these  analyses,  it  is  also  im¬ 
portant  to  note  that  a  number  of  other  hazard  anal¬ 
ysis  tools  are  available  to  the  safety  engineer  to  aid 
in  discovery  and  development  of  hazards.  A  Fault 
Tree  Analysis  (FTA)  is  often  used  to  validate  the 
likelihood  of  a  hazard  identified  by  an  SSHA  or  an 
SHA.  A  Failure  Mode,  Effects,  and  Criticality  Anal¬ 
ysis  (FMECA)  is  often  used  for  similar  purposes. 


Other  analyses— such  as  Bent  Pin,  Barrier,  and 
Common  Cause  Analyses— can  be  used  to  exam¬ 
ine  very  specific  causes  of  a  given  hazard  and  will 
augment  the  basic  analyses  listed. 

The  MIL-STD-882  analysis  sequence  is  de¬ 
signed  to  provide  the  safety  engineer  with  a  struc¬ 
tured  approach  to  discovering,  documenting, 
and  developing  mitigations  for  the  hazards  in¬ 
herent  in  a  system.  However,  when  focusing  on 
the  explosive  component  of  the  system,  special 
consideration  must  be  given  to  evaluating  the 
characteristics  of  the  energetic  materials  them¬ 
selves.  For  this  reason,  a  number  of  explosives- 
specific  tests,  analyses,  and  reviews  are  necessary 
in  an  explosives  safety  study.  These  studies  com¬ 
plement  the  MIL-STD-882  sequence  and  aid  the 
safety  engineer  in  developing  the  data  specific  to 
explosives  hazards.  This  list  includes,  but  is  not 
limited  to,  the  following: 

•  Energetic  Qualification 

•  Programmatic  Environment,  Safety,  and 
Health  Evaluation  (PESHE) 

•  IM  and  Hazard  Classification  Testing 

•  Electromagnetic  and  Electrical  Testing 

•  Packaging  and  Replenishment 

•  Explosive  Ordnance  Disposal 

•  Firefighting 

•  Quality  Evaluation 

•  Demilitarization  and  Disposal 

Energetic  Qualification 

To  a  large  extent,  explosives  and  other  ener¬ 
getics  are  not  interchangeable  in  their  uses.  For 
example,  a  good  booster  explosive  is  likely  to  be 
too  sensitive  to  be  used  as  a  main  charge  explo¬ 
sive,  whereas  a  main  charge  explosive  would  like¬ 
ly  not  function  when  struck  by  a  stab  detonator  in 
a  fuze.  To  preserve  both  safety  and  performance, 
each  type  of  explosive  must  be  used  in  an  applica¬ 
tion  for  which  it  is  capable.  This  involves  a  qualifi¬ 
cation  program  to  evaluate  the  properties  of  each 
explosive  and  verify  that  it  is  useable  and  safe  for 
its  stated  purpose.  Qualification  is  a  two-step  pro¬ 
cess.  First,  an  explosive  is  “qualified”  to  perform 
an  explosive  function — such  as  primary  explo¬ 
sive,  booster  explosive,  propellant,  etc.— based  on 
the  results  of  a  series  of  tests  of  the  raw  explosive. 
Second,  once  an  explosive  has  been  qualified  for  a 
function,  it  can  be  utilized  for  that  function  in  a 
specific  application  and  tested  in  that  design  to  be¬ 
come  qualified  in  that  application,  known  as  Final 
(Type)  Qualification.  NOSSA,  Code  N8  maintains 
the  list  of  all  Qualified  and  Final  (Type)  Qualified 
explosives  in  the  Navy  and  is  the  point  of  contact 
for  establishing  these  qualifications. 
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Programmatic  Environment, 
Safety,  and  Health  Evaluation 
(PESHE) 

Significant  environmental  issues  often  arise 
during  the  development,  production,  and  test  of  a 
new  weapon  or  system.  The  use  of  hazardous  ma¬ 
terials  and  the  desired  minimization  of  these  mate¬ 
rials,  environmental  impacts  of  storage  or  testing, 
and  effects  on  endangered  species  or  marine  mam¬ 
mals  all  have  to  be  addressed  by  the  program.  This 
is  usually  captured  in  the  PESHE. 

Noise,  toxicity,  and  other  health  issues  that 
potentially  could  be  induced  by  a  program  are  of 
interest,  as  is  compliance  with  the  National  Envi¬ 
ronmental  Protection  Act  (NEPA),  environmen¬ 
tal  impact  and  assessments,  and  other  pertinent 
laws  and  executive  orders.  The  PESHE  is  a  living 
document,  usually  started  early  in  a  program  and 
updated  periodically  to  support  specific  program 
milestones.  Its  final  version  should  be  sufficiently 
detailed  to  support  a  request  for  fielding  of  an  ex¬ 
plosive  ordnance  item.  When  conducting  a  safety 
assessment  of  an  explosive  item,  the  safety  engi¬ 
neer  should  ensure  a  basic  relationship  with  their 
local  environmental  experts. 

Insensitive  Munitions  and  Hazard 
Classification  Testing 

Key  to  any  explosives  safety  is  how  the  explo¬ 
sive  responds  to  potentially  hazardous  external 
stimuli.  Insensitive  munitions  and  hazard  classi¬ 
fication  testing  are  utilized  to  characterize  the  re¬ 
sponse  of  munitions  to  stimuli  such  as  heat,  flame, 
and  external  object  impact,  as  well  as  their  re¬ 
sponse  to  the  functioning  of  other  ordnance  in 
close  proximity,  known  as  sympathetic  reaction. 
The  results  of  this  testing  aid  the  safety  engineer 
in  determining  necessary  mitigations  for  exposure 
to  hazardous  external  stimuli  throughout  the  life 
cycle  of  the  explosive  item.  NOSSA  N8  also  man¬ 
ages  the  Navy  IM  program.  All  issues  related  to 
the  choice  and  qualification  of  explosives  must  be 
coordinated  with  NOSSA  N8  in  accordance  with 
the  appropriate  series  of  NAVSEA  Instructions 
(NAVSEAINSTs): 

•  8020.3 —Department  of  Defense  Explosive 
Hazard  Classification  Procedures 

•  8020.5,  Qualification  and  Final  (Type)  Quali¬ 
fication  Procedures  for  Navy  Explosives  (High 
Explosives ,  Propellants ,  Pyrotechnics ,  and 
Blasting  Agents) 

•  8020.8— Department  of  Defense  Ammunition 
and  Explosives  Hazard  Classification  Proce¬ 
dures 

•  8010.5— Navy  Weapon  System  Safety 


Electromagnetic  and 
Electrical  Testing 

Modern  shipboard  and  battlefield  environ¬ 
ments  are  alive  with  unseen  electromagnetic  en¬ 
ergy.  The  numerous  radars  and  communications 
devices  aboard  ship  and  in  the  field  can  couple 
with  ordnance  items  and  control  systems,  induc¬ 
ing  voltage  and  current  in  firing  and  control  cir¬ 
cuits  that  can  create  hazards  described  as  HERO. 
In  addition,  proximity  to  potential  electrostat¬ 
ic  discharge  may  induce  similar  hazards.  Design 
techniques  must  be  considered  to  minimize  the 
effects  of  these  environments.  Testing  and  analy¬ 
sis  is  necessary  to  determine  the  vulnerability  of 
an  explosive  item  and  to  demonstrate  the  degree 
of  effectiveness  of  design  mitigations  in  mitigating 
potential  hazards.  In  the  case  where  safety  from 
these  effects  is  not  designed  into  the  system,  this 
testing  helps  the  safety  engineer  to  determine  pro¬ 
cedural  mitigations  for  protecting  ordnance  from 
these  invisible  threats. 

Packaging  and  replenishment 

The  sensitivity  of  explosive  materials  and  the 
ability  to  restrict  the  potential  impact  of  external 
stimuli  during  transportation  and  storage  is  a  vital 
element  for  consideration  in  an  explosives  safety 
analysis.  For  this  reason,  how  the  item  is  packaged 
for  the  various  logistical  phases  of  its  life  cycle  is 
paramount  to  safety.  The  Department  of  Transpor¬ 
tation  (DOT)  manages  the  certification  of  packag¬ 
es  intended  to  pack  weapons  and  other  ordnance. 
DOT  has  delegated  this  authority  to  the  services  for 
their  individual  items.  The  Naval  Packaging,  Han¬ 
dling,  Support,  and  Transportation  (PHS&T)  Cen¬ 
ter  at  the  Naval  Weapons  Station,  Earle,  New  Jersey, 
is  the  Navys  center  of  expertise  for  all  PHS&T  is¬ 
sues.  Certification  of  a  package  involves  a  discrete 
series  of  tests  to  demonstrate  the  survivability  of 
the  package  under  real-life  conditions  and  the  abil¬ 
ity  of  a  package  to  withstand  these  conditions.  The 
PHS&T  Center  can  design  and  certify  a  package  or 
can  examine  developed  packaging  and  test  to  veri¬ 
fy  it  meets  DOT  standards. 

Explosive  Ordnance  Disposal 

One  of  the  more  important  configurations  for 
packaging  is  the  development  of  the  fleet  issue  unit 
load  (FIUL).  This  describes  how  smaller  boxes  are 
arranged  on  a  standard  pallet,  such  that  the  pallet 
of  ordnance  can  be  transferred  from  ship  to  ship 
during  connected  replenishment  (CONREP)  or 
by  helicopter  during  vertical  replenishment  (VER- 
TREP).  Certifying  a  FIUL  for  CONREP  involves 
passing  the  original  packaging  tests,  as  well  as 
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demonstrating  compliance  to  HERO  and  electro¬ 
static  discharge  (25  kV)  requirements.  Certifying 
a  FIUL  for  VERTREP  involves  an  extra  step  man¬ 
aged  by  the  U.S.  Army. 

The  desire  to  protect  not  just  friendly  forces  but 
also  noncombatants  is  a  high  priority  in  modern 
ordnance  development.  Thus,  the  ability  to  “ster¬ 
ilize”  the  area  after  testing  or  hostilities  in  order  to 
protect  the  innocent  is  a  driving  force  behind  the 
attention  paid  to  unexploded  explosive  ordnance 
(UXO).  All  explosive  ordnance  items  entering  the 
Navy  or  Marine  Corps  inventory  are  required  to 
have  validated  procedures  for  rendering  them  safe 
by  an  explosive  ordnance  disposal  (EOD)  team. 
Items  under  development  or  in  use  may  experi¬ 
ence  malfunctions,  leaving  behind  UXO  that  must 
be  rendered  safe  by  a  trained  EOD  team.  Testing  of 
ordnance  items  is  necessary  for  the  development 
of  the  procedures  and  data  required  by  the  EOD 
team  in  order  for  them  to  maintain  the  knowledge 
and  information  on  any  item  being  stored,  han¬ 
dled,  tested,  or  used,  so  that  they  can  safely  manage 
these  malfunctioned  items. 

Firefighting 

The  addition  of  any  new  explosive  item  to  ex¬ 
isting  inventory  mandates  a  review  of  firefighting 
procedures.  New  energetic  mixes  in  weapons  be¬ 
ing  developed  may  contain  materials  that,  when 
ignited,  are  not  responsive  to  existing  firefight¬ 
ing  methods.  Shipboard  firefighting  capabilities 
are  usually  considered  outside  of  the  purview  of 
the  safety  community  except  when  the  addition 


of  a  new  weapon  system  or  a  change  in  an  exist¬ 
ing  system  adversely  affects  the  existing  firefight¬ 
ing  system.  New  explosive  items  may  require  the 
development  of  new  fire- suppression  methodolo¬ 
gies.  While  the  approval  of  those  methodologies  is 
the  responsibility  of  a  dedicated  office  in  NAVSEA, 
Code  05P4,  that  office  will  often  ask  the  safety  en¬ 
gineer  and  the  WSESRB  for  inputs  on  the  over¬ 
all  effects  of  safety  to  the  system  and  the  ship,  as 
these  issues  are  considerations  in  the  hazard  analy¬ 
sis  performed  on  the  item. 

Quality  Evaluation 

Ordnance  safety  in  the  fleet  depends  both  on 
the  initial  safety  and  quality  of  a  weapon  when  it 
enters  the  fleet  and  its  retained  quality  after  experi¬ 
encing  the  rigors  of  fleet  use  and  stowage.  Age  and 
exposure  to  various  environmental  factors — such 
as  heat,  cold,  and  humidity— may  contribute  to  de- 
stabilization  of  explosives  over  time.  Development 
of  a  Quality  Evaluation  Plan  for  ordnance  is  essen¬ 
tial  to  ensuring  that  explosives  maintain  safe  char¬ 
acteristics  over  the  lifetime  of  their  service  use.  All 
weapon  programs  are  required  to  establish  a  qual¬ 
ity  evaluation  program  to  monitor  the  quality  of  a 
weapon  as  it  ages  in  the  fleet.  NOSSA  N8  oversees 
this  process  for  the  Navy  and  aids  by  maintaining 
controlled  samples  of  all  propellants  used  in  the 
fleet  and  schedules  for  periodic  re-examination  of 
other  ordnance  items. 

DEMILITARIZATION  AND  DISPOSAL 

As  with  any  production  item,  the  likelihood  is 
that  not  all  ordnance  produced  will  be  needed.  At 
some  point,  an  explosive  item  must  be  disposed  of 
when  using  it  is  no  longer  safe  or  productive.  Each 
program  is  required  to  have  a  plan  to  demilitarize 
or  dispose  of  all  items  safely  at  the  end  of  their  life¬ 
time;  requirements  for  disposal  differ  depending 
on  the  materials  present  in  the  item.  Guidance  for 
developing  an  appropriate  plan  for  demilitariza¬ 
tion  and  disposal  may  be  found  in  NAVSEAINST 
8027.2  (Series),  Demilitarization  Disposal  Require¬ 
ments  Relating  to  the  Design  of  the  New  Modifica¬ 
tion  of  Ammunition  Items. 

While  this  article  presents  a  number  of  consid¬ 
erations  in  conducting  a  safety  study  on  explosive 
ordnance  items,  it  is  not  meant  as  a  comprehensive 
primer  in  explosives  safety.  An  explosive  ordnance 
safety  program  comprises  many  elements— a  num¬ 
ber  of  analyses  and  extensive  review  and  approval. 
While  the  process  may  be  extensive  and  laborious, 
it  is  critical  to  ensure  that  weapons  meet  their  de¬ 
sign  objectives  and  are  safe  in  the  hands  of  those 
who  use  them. 
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The  Execution  and  Evolution 
of  Combat  System  Safety 

By  Mike  Zemore 


a 


Combat  system  (CS)  safety  is  the  practice  of  identifying  safety  risks  in  a  system-of- 
systems  (SoS)  context.  This  article  discusses  the  foundational  elements  of  the  Combat 
System  Safety  Program  (CSSP)  as  derived  collaboratively  with  the  Program  Executive 
Office  for  Integrated  Warfare  Systems  (PEO  IWS)  Chief  Engineer.  It  also  discusses  the 
role  of  the  Combat  System  Principal  for  Safety  (CS  PFS),  integration  within  the  Naval 
Sea  Systems  Command  (NAVSEA)  battle  group  action  teams  and  strike  group  teams, 
and  the  development  of  SoS  safety  analytical  methodologies  that  preceded  and  influ¬ 
enced  Navy  policy.  Focus  is  directed  to  the  significance  of  the  historical  perspective  of 
CS  safety,  definition  of  influential  factors,  collection  of  lessons  learned,  and  the  evolving 
methods  to  preserve  the  engineering  value  inherent  in  the  SoS  safety  engineering  ap¬ 
proach  for  the  Navy. 

CS  safety  was  initiated  in  2001  and  gained  significant  thrust  in  2002,  after  the  Weap¬ 
on  System  Explosives  Safety  Review  Board  (WSESRB)  exercised  their  authority  to  dis¬ 
approve  a  Combat  System  Ship  Qualification  Test  (CSSQT)  event  until  an  integrated  CS 
safety  analysis  was  completed. 

Previously,  system  safety  analyses  and  practices  were  applied  to  individual  combat 
system  elements  (CSEs)  and  had  been  demonstrated  to  be  effective  in  identifying  haz¬ 
ards  and  mitigating  mishap  risk.  However,  the  board  recognized  the  trend  in  overall  CS 
complexities  and  the  reliance  on  integration  of  the  many  individual  systems  for  mission 
success.  That  level  of  integration  understandably  drives  new  hazard  considerations  for 
safe  operations.  Specifically,  the  board  wrote: 

The  WSESRB  believes  that  many  safety  issues  associated  with  the 
interface  of  CS  elements  do  not  receive  adequate  identification  or  at¬ 
tention  due  to  the  lack  of  a  comprehensive,  integrated  CS  safety  effort. 

The  WSESRB  s  CSSQT  disapproval  provided  the  primary  impetus  for  a  CS  safety  ef¬ 
fort  for  USS  Nimitz  in  2002.  However,  the  community  had,  in  fact,  already  recognized 
the  need  for  an  integrated  CS  safety  effort  and  was  in  the  process  of  establishing  the 
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A  RIM-7P  NATO  Sea  Sparrow  Missile  launches  from  Mount  Four  aboard  the  Nimitz-c\ass  aircraft  carrier 
USS  Abraham  Lincoln  (CVN  72)  during  a  stream  raid  shoot  exercise.  Lincoln’s  self-defense  systems  fired  four 
Sea  Sparrow  missiles,  engaging  and  destroying  two  BQM-74E  turbojet-powered  drone  aircraft,  and  a  High-Speed 


Maneuvering  Surface  Threat  (HSMST)  remote-controlled  Rigid  Hulled  Inflatable  Boat  (RHIB)  during  the  event. 
Lincoln  and  embarked  Carrier  Air  Wing  (CVW)  2  are  underway  off  the  coast  of  Southern  California  conducting 
Tailored  Ship’s  Training  Availability  (TSTA). 

U.S.  Navy  photo  by  Mass  Communication  Specialist  2nd  Class  M.  Jeremie  Yoder  (RELEASED) 


foundational  elements  for  that  evolution.  By  2001, 
the  Naval  Surface  Warfare  Center,  Dahlgren  Di¬ 
vision  (NSWCDD)  had  begun  working  with  Pro¬ 
gram  Executive  Office  for  Expeditionary  Warfare 
(PEO  EXW)  and  PEO  carriers  to  establish  an  over¬ 
arching  system  safety  role  for  aircraft  carriers  and 
amphibious  assault  ships.  Focusing  a  safety  effort 
at  this  level  of  integration  was  a  tremendous  op¬ 
portunity  to  advance  systems  safety  engineering 
methodologies  and  collaborative  efforts  to  influ¬ 
ence  the  CS  safety  posture  to  eliminate  potential 
accidents.  Also  in  2001,  NSWCDD  was  working 
with  PEO  ships  to  execute  a  CS  safety  effort  for 
the  new  construction  of  the  amphibious  transport 
dock  (LPD) -class  ship.  Thus,  the  integrated  SoS 
safety  methodologies  and  techniques  were  at  that 
time  in  their  formative  stages,  but  had  not  gelled 
into  a  cohesive  SoS  safety  engineering  process. 

The  WSESRB  disapproval,  therefore,  forced  the 
established  framework  for  CS  safety  to  be  fully  de¬ 
veloped  and  exercised  in  order  to  gain  concurrence 
for  USS  Nimitz  CSSQT  and  deployment.  This  ac¬ 
tion  thrust  the  safety  community  and  the  CS  safety 
role  to  new  heights.  Almost  instantly,  NAVSEA  06 
and  program  offices  aligned  to  address  the  WSESRB 
finding.  USS  Nimitz  was  a  special  case,  in  that  the 
Nimitz  Battle  Group  Action  Team  (NIMBGAT), 
previously  established  as  a  risk  mitigation  strate¬ 
gy,  employed  cross-organizational  coordination  to 


support  successful  deployment  of  USS  Nimitz.  At 
the  time,  the  Deployment-30  months  (D-30)  cer¬ 
tification  process  was  applicable,  and  close  coor¬ 
dination  was  required  between  the  NIMBGAT 
and  NAVSEA  06  as  the  certification  activity.  The 
NIMBGAT  accepted  the  CS  PFS  as  a  team  mem¬ 
ber  and  designated  the  CS  PFS  as  the  Safety  Lead 
for  USS  Nimitz. 

With  the  importance  of  USS  Nimitz  and  its 
projected  deployment  timeline,  NSWCDD  worked 
directly  with  the  PEO  IWS  (formerly  known  as 
the  PEO  for  Theater  Surface  Combatants  (TSC)) 
Chief  Engineer,  the  NIMBGAT,  the  WSESRB, 
and  the  many  stakeholders  to  establish  and  exe¬ 
cute  the  CSSP.  This  was  no  ordinary  safety  effort 
given  that  most  of  the  SoS  safety  methodologies 
needed  definition  and  refinement  to  accomplish 
value-added  safety  analytical  work.  USS  Nimitz , 
only  weeks  from  a  CSSQT  and  follow-on  deploy¬ 
ment,  required  detailed  safety  analyses  performed 
on  the  integrated  CS  in  order  to  support  these  im¬ 
portant  milestones.  It  was  a  daunting  task,  but  it 
was  also  a  great  challenge  and  great  opportuni¬ 
ty  for  many  dedicated  individuals  to  serve  this 
nation  and  our  fleet.  Beneficial  to  this  endeav¬ 
or  was  that  the  NIMBGAT  was  an  extraordinary 
group.  They  were  exceptional  in  their  knowledge, 
leadership,  planning  and  execution  in  preparing 
USS  Nimitz  for  deployment.  Likewise,  the  PEO 


NAVSEA  Warfare  Centers 


Volume  7,  Issue  No.  3 


87 


f 


Systems  Safety  Engineering 

Types  of  System  Safety  Efforts 


USS  Nimitz 

Integrated  Combat  System  Capability 


USS  Nimitz  Combat  System  provides: 

•  State-of-the-Art  Sensor  Integration 

•  Quick  Reaction  Through  Automation  & 
Efficient  Human  /  Machine  Interface 

•  Coordination  of  Weapons 


.ENGAG 


IWS  Chief  Engineer,  a  Navy  Captain,  was  excep¬ 
tional  as  an  innovator,  motivator,  and  leader.  The 
successful  initiation  and  execution  of  the  CSSP  for 
USS  Nimitz  was  due  to  the  dedication  of  these  in¬ 
dividuals— and  many  others— to  mission  success. 

The  CS  Safety  approach  was  carefully  crafted 
utilizing  (MIL-STD)  882  series,  Standard  Practice 
for  System  Safety.  The  overall  goal  was  to  identi¬ 
fy,  communicate,  and  mitigate  integration  hazards 
not  previously  identified  through  individual  CSE 
safety  programs.  The  approach  stressed  engineer¬ 
ing  analyses  of  the  integrated  CS  while  assessing 
CSE  analysis  results  for  potential  integration  safe¬ 
ty  risks.  The  effort  was  unique  given  that  hazards 
associated  with  the  integration  of  multiple  CSEs 
would  likely: 

•  Have  multiple  CSEs  with  contributing  haz¬ 
ard  causal  factors,  or 

•  Have  multiple  CSEs  contributing  to  hazard 
mitigation  strategies,  or 

•  Have  multiple  risk  acceptance  authorities 
providing  residual  risk  acceptance 

To  ensure  consistent  development,  documen¬ 
tation  and  execution  of  the  CSSP,  NSWCDD  devel¬ 
oped  a  Combat  System  Safety  Management  Plan. 
The  plan  captured  the  methodologies,  techniques, 
roles,  and  responsibilities  associated  with  estab¬ 
lishing  and  executing  the  CSSP.  PEO  IWS,  respon¬ 
sible  for  the  majority  of  surface  warfare  CSEs,  was 


the  obvious  owner  of  the  document.  The  2002  draft 
plan  was  disseminated  throughout  PEO  IWS  for 
review  and  disposition  and  subsequently  updated 
to  include  lessons  learned  after  the  PEO  IWS-initi- 
ated  safety  study  on  integrated  training  systems  for 
surface  ships. 

Of  particular  emphasis  in  the  CS  safety  ap¬ 
proach  was  the  application  of  analytical  methods 
for  hazard  identification  and  detailed  risk  assess¬ 
ment.  The  methods  included  analysis  of  all  possi¬ 
ble  failure-mode  root  causes  associated  with  the 
following: 

•  Integration  of  human  actions  and  interac¬ 
tions  across  numerous  systems 

•  Implementation  of  CS  safety- critical  func¬ 
tions  and  system  interactions 

•  Hardware  failures  and  their  impact  on  CS 
safety-critical  functions  and  system  integra¬ 
tions 

•  Software  deficiencies  and  their  impact  on  CS 
safety-critical  functions  and  system  integra¬ 
tions 

To  successfully  execute  the  CS  safety  approach, 
the  team  had  to  define  specific  criteria  to  main¬ 
tain  focus  on  the  safe  integration  of  CSEs.  Through 
the  conduct  of  the  Combat  System  Safety  Work¬ 
ing  Group  (CSSWG),  the  team  defined  CS-lev- 
el  safety-critical  functions  and  initiated  a  trace  of 
the  safety  functions  to  individual  CSEs.  The  team 
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also  identified  CS-level  hazards  and  initiated  the 
assessment  of  CSEs  for  causal  factor  contributors. 
This  led  to  the  realization  that  safety  “scrutiny”  of 
individual  CSEs  could  be  guided  by  defining  the 
terms  safety  critical  and  safety  related.  Safety-crit¬ 
ical  CSEs  were  those  that  directly  controlled  weap¬ 
ons  and  needed  the  highest  level  of  safety  analysis 
rigor.  Safety-related  CSEs  were  those  that  provid¬ 
ed  data  used  in  controlling  weapons  but  performed 
no  controlling  functions.  Safety-related  CSEs  typi¬ 
cally  required  less  safety  analysis  rigor. 

Since  the  overall  SoS  effort  hinged  on  success¬ 
ful  collaboration  with  CSE  safety  leads,  it  was  para¬ 
mount  that  the  safety  analysis  criteria  and  approach 
be  well  communicated  to  CSE  Safety  Leads  in  or¬ 
der  to  enlist  their  assistance.  Collaborative  sessions 
aided  in  determining  CSE  relevance  to  CS  safety 
functions  and  in  applying  CSE  safety  analysis  re¬ 
sults  to  determine  possible  CS-level  hazards.  Al¬ 
though  hazard  identification  and  mitigation  were 
primary  goals,  there  were  ancillary  responsibilities 
for  the  CS  PFS.  The  CS  PFS  would  also: 

•  Provide  safety  leadership  for  the  Com¬ 
bat  System  Safety  Integrated  Product  Team 
(IPT)  for  Strike  Groups/ Action  teams 

•  Provide  a  CS  Safety  point  of  contact  (POC) 
with  NAVSEA  06  concerning  the  safety  of 
CS  configurations  certification 


•  Optimize  safety  costs  through  coordinated 
engineering  efforts  and  the  Software  Systems 
Safety  Technical  Review  Panel  (SSSTRP)/ 
WSESRB  CS  reviews 

Possibly  the  most  vital  aspect  in  conducting 
the  CSSP  was  the  collection  of  CSE  safety  engi¬ 
neering  data.  To  facilitate  this,  the  CS  Safety  Team 
initiated  a  series  of  “data  calls”  as  a  collaboration 
vehicle.  The  data  calls  targeted  individual  CSE 
Safety  Leads  as  members  of  the  CSSWG.  Response 
to  data  calls  was  essential  for  conducting  the  first 
CS  safety  analysis— USS  Nimitz  CS  Preliminary 
Hazard  Analysis.  The  data  calls  were  also  instru¬ 
mental  in  the  follow-on  analysis— USS  Nimitz  CS 
System  Hazard  Analysis.  Significantly,  tuning  of 
this  data  call  process  also  prepared  the  CS  Safety 
Team  for  safety  studies  on  upcoming  CS  configu¬ 
rations  as  the  team  refined  the  analytical  capabili¬ 
ties  and  evolved  the  discipline. 

The  success  of  the  data  call  process  and  col¬ 
laborative  sessions  was  largely  attributable  to  the 
community  having  a  focused  goal  on  USS  Nim¬ 
itz ,  with  support  from  the  NIMBGAT.  The  data 
call  process  targeted  three  types  of  data  for  assess¬ 
ment  at  the  CS  level:  future  capabilities  and  func¬ 
tionality,  safety  and  verification  products,  and 
known  risks.  Implementation  of  the  data  calls  was 
collaborative  in  that  the  CS  Safety  Team  would 
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“give”  information  during  the  call  process  and 
would  “get”  data  from  the  CSE  Safety  Lead  in  re¬ 
turn  (see  Figure  1). 

The  hazard  identification  and  safety  verifica¬ 
tion  process  also  relied  heavily  on  integrating  the 
CS  Safety  Team  into  the  development  and  inte¬ 
gration  testing  process.  Since  integration  hazards 
are  not  always  identifiable  through  purely  analyti¬ 
cal  studies,  the  team  required  requisite  system  per¬ 
formance  knowledge  best  acquired  through  actual 
system  operation.  For  safety  verification,  the  inte¬ 
gration  test  lab,  combined  with  shipboard  testing, 
provided  the  necessary  venue  for  end-to-end  ver¬ 
ification  of  CS  safety-critical  functions  and  imple¬ 
mented  hazard  mitigations. 

Although  the  CSSP  was  on  track  for  USS  Nim- 
itz ,  it  was  an  aggressive  engineering  venture,  where 
the  pending  milestones  for  deployment  provided 
little  room  for  error.  As  a  result,  the  team  decid¬ 
ed  that  a  memorandum  of  agreement  (MOA)  was 
necessary  to  guide  the  formal  review  and  certifi¬ 
cation  process.  The  MOA  outlined  the  approach 


and  responsibilities  to  mitigate  programmatic  risk, 
understanding  that  this  was  the  first  ever  surface 
ship  CS  WSESRB  review  with  follow-on  NAVSEA 
06  warfare  systems  certification.  The  CS  Safety 
Team  drafted  the  MOA  with  responsible  organiza¬ 
tions  including  the  WSESRB,  NAVSEA  06,  PEOs, 
and  the  CS  PFS.  The  MOA  was  never  signed  as  a 
formal  agreement,  but  all  parties  acknowledged 
the  content.  That  acknowledgment  was  effective 
in  providing  the  necessary  facilitation  and  coor¬ 
dination  for  USS  Nimitz  configuration  during  the 
formal  review  and  certification  process.  The  con¬ 
tent  of  the  draff  MOA  was  later  used  in  the  de¬ 
velopment  of  the  warfare  certification  instruction 
NAVSEAINST  9410.2,  Naval  Warfare  Systems  Cer¬ 
tification  Policy ,  and  the  update  to  WSESRB  in¬ 
struction  NAVSEAINST  8020. 6E,  Department  of 
the  Navy  Weapon  System  Explosives  Safety  Review 
Board.  Each  addresses  CS  safety  requirements. 

As  discussed  earlier,  the  CS  safety  analysis  ef¬ 
fort  was  no  ordinary  system  safety  effort,  so  no  or¬ 
dinary  SSSTRP  and  WSESRB  would  suffice.  The 
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The  aircraft  carrier  USS  Nimitz  (CVN  68),  the  guided-missile  cruiser  USS  Chosin  (CG  65), 
the  guided-missile  destroyers  USS  Sampson  (DDG  102)  and  USS  Pinkney  (DDG  91),  and 
the  guided-missile  frigate  USS  Rentz  (FFG  46)  operate  in  formation  in  the  South  China 
Sea.  The  Nimitz  Carrier  Strike  Group  is  conducting  operations  in  the  U.S.  7th  Fleet  area 
of  responsibility. 

(U.S.  Navy  photo  by  Mass  Communication  Specialist  1st  Class  David  Mercil/Released) 


SSSTRP,  held  in  November  2002,  was  a  2-day  ses¬ 
sion,  with  detailed  review  of  all  software,  software 
safety  processes,  software  configurations,  and  risk. 
The  CS  PFS  presented  the  CS  mishap  risk  assess¬ 
ment  methodology  and  analysis  results,  where 
causal  factors  were  evaluated  individually  and  col¬ 
lectively  within  the  context  of  the  integrated  sys¬ 
tem.  The  review  was  deemed  successful,  and  the 
panel  concluded  with  its  recommendations  being 
provided  to  the  WSESRB.  The  WSESRB  review  fol¬ 
lowed  in  December  2002.  The  importance  of  hav¬ 
ing  a  first-ever  CS  safety  review  that  covered  the 
integration  of  numerous  CSEs  within  the  con¬ 
text  of  integrated  CS  led  the  board  to  its  first-ev¬ 
er  Senior  Level  WSESRB  that  is  now  documented 
in  NAVSEAINST  8020.6E.  During  the  review,  the 
characterization  and  quantification  of  mishap  risk 
potential  based  on  the  analytical  results  was  com¬ 
municated  within  the  context  of  a  collective  SoS. 
At  the  conclusion  of  the  review,  the  WSESRB  wrote 
in  their  findings: 

The  WSESRB  concurs  that  the  process 
used  adequately  identifies  USS  Nimitz  ship 


self-defense  CS  residual  risk,  and  based  on 
that  process,  the  residual  risk  is  at  an  accept¬ 
able  level  for  deployment. 

The  culmination  of  USS  Nimitz’s  CS  safety 
analysis  and  review  process  was  significant  in  that 
it: 

•  Characterized  risk  for  the  entire  CS 

•  Established  the  basis  to  mitigate  risks  as  a 
distributed  or  shared  responsibility 

•  Emphasized  the  need  for  integration  of  the 
CS  Safety  Team  in  all  integration  test  events 

•  Laid  the  groundwork  for  the  CS  safety  in¬ 
volvement  in  the  definition  and  documenta¬ 
tion  of  safety-related  information  provided 
to  the  ship 

USS  Nimitz’s  CS  safety  effort  established  the 
precedent  for  conducting  a  CSSP.  Although  tech¬ 
niques  and  methods  continue  to  evolve,  the  WS¬ 
ESRB  and  certification  authorities  continue  to 
leverage  the  scope,  methods,  techniques,  collabor¬ 
ative  efforts,  and  communications  defined  during 
this  effort  as  the  baseline  for  integrated  safety  anal¬ 
yses  and  review. 
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The  practice  of  combat  system  (CS)  safety  engineering  was  established  to  address 
CS  safety  issues  by  focusing  on  integrated  hazard  methodology  and  integration  hazards, 

i  which  typically  fall  outside  the  bounds  of  individual  combat  system  element  (CSE)  sys¬ 
tem  safety  program  efforts.  This  article  describes  the  processes  and  methodologies  for 
conducting  a  CS  safety  program  in  an  effort  to  identify  and  characterize  CS  integration 
hazards  and  provide  engineering  recommendations  to  eliminate  or  mitigate  them  to  an 
acceptable  level. 

CSEs  have  historically  been  effective  executing  a  system  safety  program  on  their 
system  to  identify  and  mitigate  risks  in  the  context  of  their  system.  When  each  of  these 
CSEs  is  integrated  to  make  up  a  CS  however,  existing  CSE  hazards  may  create  a  greater 
risk  at  the  CS  or  system-of-systems  (SoS)  level,  and/or  new  safety  hazards  may  be  intro¬ 
duced  as  a  result  of  the  integration.  The  practice  of  CS  safety  engineering  was  established 
to  address  these  integration  hazards.  The  processes  and  methodologies  utilized  to  con¬ 
duct  a  CS  safety  program  are  discussed  in  this  article. 

To  begin,  let  us  define  CS  and  CSE  as  utilized  in  the  context  of  this  article: 

Combat  System  (CS)— An  integrated  set  of  systems  capable  of  accomplishing  the 
plan,  detect,  control,  and  engage  functions  across  all  warfighting  mission  areas. 

Combat  System  Element  (CSE)— A  weapon  control  system,  weapon,  or  other  sys¬ 
tem/component  that  is  necessary  for  the  completion  of  one  or  more  of  the  ships  warfare 
missions.  CSEs  exchange  information  with  other  CSEs  via  a  digital  or  analog  interface. 

CS  safety  can  be  broken  down  into  three  process  phases,  though  the  efforts  with¬ 
in  each  process  phase  can  be  executed  concurrent  with  efforts  in  another  process  phase: 

Jl.  CS  safety  planning  and  management 
2.  Hazard  analysis  and  risk  reduction 
3.  Hazard  tracking  and  CS  residual  risk  determination 

CS  Safety  Planning  and  Management  Process 

Before  executing  a  CS  safety  program,  an  understanding  of  the  CSEs  that  make  up 
the  CS  and  determination  of  their  level  of  criticality  is  required.  CSE  criticality  determi¬ 
nation  is  important,  as  this  will  assist  in  the  prioritization  of  resources  when  planning 
and  executing  the  CS  safety  program.  NAVSEAINST  8020. 6E,  Department  of  the  Navy 
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Weapon  Systems  Explosives  Safety  Review ,  provides 
the  following  definitions  in  assessing  CSE  critical¬ 
ity: 

•  Safety-Critical  CSE— A  CSE  that  directly 
or  indirectly  controls— or  has  the  potential 
to  control — ordnance,  or  provides  informa¬ 
tion  necessary  to  the  safe  selection,  arming, 
release,  firing,  or  jettisoning  of  an  ordnance 
item  with  respect  to  a  specific  event  (i.e., 
missile  test  firing  or  deployment). 

•  Safety- Related  CSE— A  CSE  that  interfaces 
to  a  safety-critical  CSE,  whose  failure  would 
result  in  the  increased  risk  of  an  ordnance- 
related  mishap.  Determination  is  made 
based  on  engineering  judgment  utilizing 
the  Combat  System  Safety  Working  Group 
(CSSWG)  and  the  documented  CS  safety- 
critical  functions  and  potential  CS-related 
mishaps. 

Figure  1  depicts  these  process  phases  and  the 
tasks  associated  with  each  and  will  be  discussed 
throughout  the  remainder  of  this  article. 

Execution  of  a  CS  safety  program  requires  a 
vast  array  of  knowledge  and  understanding  of  the 
CSEs  making  up  the  CS,  and  heavy  reliance  on  the 


CSE  safety  programs  sharing  detailed  informa¬ 
tion  when  hazards  are  identified  as  contributing 
to  CS-level  hazards.  The  CSSWG,  with  represen¬ 
tation  from  each  CSE  Principal  For  Safety  (PFS) 
or  safety  lead— along  with  representation  from 
organizations  associated  with  the  system  acquisi¬ 
tion  program — is  the  forum  in  which  data  sharing 
and  collaborative  assessment  of  technical  safety 
issues  occurs.  Early  establishment  of  the  CSSWG 
is  critical  to  the  successful  execution  of  a  CS  safe¬ 
ty  program. 

The  tool  for  planning,  managing,  and  commu¬ 
nicating  when  multiple  safety  efforts  are  occurring 
on  a  CS  is  called  the  System  Safety  Management 
Plan  (SSMP).  The  SSMP  establishes  the  foun¬ 
dational  elements  necessary  for  CSEs  to  devel¬ 
op  their  System  Safety  Program  Plans  (SSPPs) 
and  provides  a  common  framework  in  which  in¬ 
dividual  CSEs  can  work  together  on  a  CS  safety 
program  while  eliminating  methodology  issues, 
minimizing  communication  problems,  and  avoid¬ 
ing  duplication  of  effort. 

Given  that  engineering  development  efforts 
may  span  years,  it  is  imperative  that  hazard  data 
be  tracked,  maintained,  and  stored  electronically 
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Figure  1.  Combat  System  Safety  Process 
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in  a  hazard  tracking  system.  The  hazard  tracking 
system  should  be  designed  to  accommodate  at  a 
minimum: 

•  A  hazard  description 

•  Any  contributing  or  causal  factors  to  the 
hazard,  as  well  as  the  hazards  potential  con¬ 
tribution  to  a  mishap 

•  Mitigations  and  verification/ validation  sta¬ 
tus  of  mitigations 

•  Current  status  of  all  hazards  and  any  actions 
assigned 

A  CS  hazard  tracking  system  must  also  ac¬ 
count  for  real  and  potential  CSE  hazards,  and  an 
assessment  of  known  CSE  causal  factors  by  the  CS 
PFS  for  their  contribution  to  CS  mishaps.  This  is 
discussed  in  greater  detail  later  in  the  article. 

Establishment  of  a  CSSWG,  SSMP,  and  haz¬ 
ard  tracking  system  establishes  the  foundation  nec¬ 
essary  to  initiate  the  next  CS  safety  process  phase: 
the  Hazard  Analysis  and  Risk- Reduction  Process 
Phase. 

Hazard  Analysis  and 
Risk-Reduction  Process 

The  Interface  Requirements  Specification 
(IRS),  the  Interface  Design  Specification  (IDS), 
and  CSE  hazard  analysis  data  are  appropriate  and 


necessary  inputs  to  the  CS  Preliminary  Hazard 
Analysis  (PHA).  As  part  of  the  CS  PHA,  safety 
functions  are  defined  consistent  with  CS  missions. 
The  safety  functions  are  then  allocated  to  applica¬ 
ble  CSEs  based  on  the  CSEs  potential  involvement 
in  the  safety  function. 

A  PHA  can  be  thought  of  as  a  rigorous  ana¬ 
lytical  exercise  in  which  top-level  mishaps  (TLMs), 
hazards,  and  causal  factors  are  hypothesized,  giv¬ 
en  the  missions  and  capabilities  of  a  system.  The 
CS  PHA  is  far  more  comprehensive,  in  that  it  con¬ 
siders  TLMs,  hazards,  and  causal  factors  in  concert 
with  CS  missions  and  capabilities  from  an  SoS  ap¬ 
proach  involving  all  safety-related  and  safety-crit¬ 
ical  CSEs.  A  TLM  is  defined  as  an  unwanted  and 
unplanned  event  in  which  there  is  a  release  of  ener¬ 
gy  that  will  have  a  detrimental  effect  on  personnel, 
equipment,  or  the  environment.  This  unplanned 
event  is  induced  by  one  or  more  hazard,  with  haz¬ 
ards  being  understood  to  mean  a  real  or  potential 
condition  that,  if  realized,  could  lead  to  a  mishap. 
In  other  words,  a  hazard  is  a  prerequisite  to  the  oc¬ 
currence  of  a  mishap.  Causal  factors  are  elements 
within  the  system  design,  implementation,  or  op¬ 
eration  that  can  lead  to  the  realization  of  a  hazard, 
and  they  fall  into  one  of  three  categories:  human 
or  operator,  hardware,  and  software.  The  CS  PHA 
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then  applies  each  TLM/hazard/causal  factor  rela¬ 
tionship  as  instantiations  to  all  applicable  CSEs. 
The  following  example  of  a  TLM/Hazard/Causal 
Factor  instantiation  relationship  is  provided  to  il¬ 
lustrate  this  concept: 

For  TLM  Intercept  of  Friendly /Nonhostile , 
one  potential  hazard  that  could  lead  to  this  mishap 
would  be  failure/ inability  to  terminate  or  suspend 
engagement.  A  causal  factor  that  could  result  in 
this  potential  hazard  being  realized  would  be  fail¬ 
ure  of  system  to  process  termination  or  suspension 
orders ,  which  may  have  a  number  of  instantiations, 
or  CSEs  that  it  may  be  applicable  to.  Figure  2  is  a 
generic  graphical  representation  of  this  concept. 

At  the  conclusion  of  a  CS  PHA,  there  is  like¬ 
ly  to  be  an  enormous  number  of  hazards,  caus¬ 
al  factors,  and  instantiations  that  will  provide  the 
foundation  for  the  start  of  the  CS  System  Hazard 
Analysis  (SHA).  The  results  of  the  CS  PHA  are  the 
foundation  for  initiation  of  the  CS  SHA.  The  focus 
of  the  CS  SHA  is  to: 

•  Fully  analyze  and  characterize  the  risk  as¬ 
sociated  with  the  hazards  and  causal  factors 
identified  in  the  CS  PHA 

•  Identify  previously  unidentified  hazards  as¬ 
sociated  with  CSE  interfaces 


•  Identify  existing  mitigations  for  CS  hazards 
and  causal  factors 

•  Recommend  actions  necessary  to  either 
eliminate  identified  CS  hazards  or  identify 
mitigation  strategies  to  control  their  risk  to 
an  acceptable  level 

To  ensure  that  appropriate  safety  analysis  rigor 
and  focus  is  applied  to  the  CS  SHA,  CSEs  and  CS 
interfaces  must  be  characterized.  Characterization 
of  CSEs  should  be  done  in  the  context  of  CS  safe¬ 
ty  functionality.  Some  key  focus  areas  to  identify 
in  characterizing  CSEs  include:  weapons,  ordnance 
and  other  energy  sources,  CSEs  dependent  upon 
data  or  information  from  another  CSE  to  execute 
CS  safety  functionality,  modes  of  operation,  and 
safety  functions  requiring  operator  involvement. 
Characterization  of  CSE  interfaces  should  focus 
on  some  key  areas  involving  critical  data  flow,  in¬ 
cluding  timing  and  other  controls  to  ensure  deliv¬ 
ery  and  processing,  data  integrity,  communication 
protocols,  and  interface  recovery  processing.  Ade¬ 
quacy  of  IDS  should  also  be  factored  into  this  ana¬ 
lytical  assessment. 

Characterization  of  CSEs  and  their  interfaces 
allows  for  a  more  targeted  approach  in  perform¬ 
ing  interface  analysis  as  part  of  the  CS  SHA.  Those 
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Figure  2.  Concept  Diagram  of  System  Hazard  Analysis 
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CSEs  and  CSE  interfaces  with  the  most  severe 
potential  for  a  safety  mishap  should  receive  the 
most  attention  with  respect  to  safety  analysis  and 
testing.  Potential  root  causes  from  all  causal  factor 
categories  must  be  considered  in  this  process,  in¬ 
cluding: 

•  Human  actions  and  interactions  involved 
with  integrating  multiple  operators  across 
multiple  CSEs 

•  Hardware  and  software  failures 

•  Design  defects  and  their  impacts  on  CS  safe¬ 
ty  functions 

Utilizing  the  instantiations  from  the  CS  PHA — 
uncertainties  due  to  immature  design,  new  CS 
capabilities  or  functionality,  potential  failure  con¬ 
ditions,  and  potential  data  errors— a  series  of  safety 
scenarios  can  be  constructed.  These  safety  scenar¬ 
ios  can  be  thought  of  as  “what-if”  constructs  and 
are  intended  to  focus  safety  analysis  and  testing  ef¬ 
forts.  Some  areas  for  consideration  include: 

•  Failure  of  safety  interlocks 

•  Mode  mismatches 


•  Safety  data  verification  errors 

•  Timing  errors  involving  safety-critical  data 
transfer  across  CSE  interfaces 

For  each  hazard  and  causal  factor  identified 
during  the  conduct  of  the  CS  SHA  or  carried  for¬ 
ward  from  the  CS  PHA,  existing  safety  mitigations 
should  be  identified  and  captured  in  the  CS  Hazard 
Tracking  Database  (CS  HTDB).  An  assessment  as 
to  the  comprehensiveness  of  the  mitigation  should 
also  be  made.  For  those  hazards  or  causal  factors 
deemed  insufficiently  mitigated,  actions  necessary 
to  either  eliminate  the  identified  CS  hazards  or 
identify  mitigation  strategies  to  control  their  risk 
to  an  acceptable  level  should  be  documented  in  the 
CS  SHA  and  captured  in  the  CS  HTDB.  Addition¬ 
ally,  adequacy  of  the  design  mitigations  relative  to 
CS  safety  concerns  captured  in  the  “what-if”  safety 
constructs  should  be  determined  by  assessing  ap¬ 
propriate  IDS,  assessing  CSE  safety  hazard  analysis 
artifacts,  and/or  collaboration  with  the  appropriate 
CSE  safety  team  or  CSE  system  engineers. 

Verification  and  validation  of  hazard  and  caus¬ 
al  factor  mitigations  designed  into  the  CS  can  be 
accomplished  via  interface  analysis  as  the  design 
continues  to  mature,  via  system  integration  testing, 
or  a  combination  of  the  two.  Integrating  CS  safety 
engineers  into  the  developmental  and  testing  pro¬ 
cesses  with  an  emphasis  on  CS  integration  testing 
is  vital  in  understanding  and  assessing  implemen¬ 
tation  of  safety  mitigations  to  eliminate  or  reduce 
CS  safety  risk.  The  CS  safety  team  should  be  directly 
involved  by  providing  system  safety  testing  input  to 
ensure  that  appropriate  levels  of  safety  function  test¬ 
ing  are  accomplished.  The  CS  safety  teams  involve¬ 
ment  during  the  conduct  of  safety  testing  to  ensure 
full  insight  and  understanding  of  any  test  anomalies 
that  occur  during  system  integration  testing  is  im¬ 
portant  in  providing  an  assessment  of  risk. 

Even  after  thoroughly  analyzing  and  testing 
CS  interfaces,  making  risk  mitigation  recommen¬ 
dations,  and  verifying  and  validating  the  mitiga¬ 
tions,  at  the  end  of  the  day  there  will  be  residual 
safety  issues  that  cannot  be  eliminated  or  that  still 
require  additional  procedural  workarounds  to  en¬ 
sure  safety  of  personnel,  equipment,  and  the  en¬ 
vironment.  The  CS  safety  team  must  provide  an 
operational  impact  assessment  of  these  procedural 
workarounds  to  ensure  that  they,  in  fact,  effective¬ 
ly  mitigate  the  risk  without  introducing  additional 
safety  issues  or  creating  a  burden  for  any  particu¬ 
lar  operator.  Commonly  referred  to  as  tactics,  tech¬ 
niques,  and  procedures  (TTP),  these  workarounds 
are  not  the  best  option  for  providing  mitigation  to 
a  known  safety  risk,  but  often  this  is  the  only  option 
left.  Because  TTP  workarounds  are  employed  by 
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humans,  it  becomes  imperative  that  they  are  writ¬ 
ten  in  clear  and  unambiguous  language,  and  can  be 
easily  invoked  by  the  operator  when  required. 

Hazard  Tracking  and  CS  Residual 
Risk  Determination 

The  CS  safety  program  HTDB  is  populated  with 
hazard  data  and  is  continually  updated  throughout 
the  life  of  the  CS  safety  program.  The  HTDB  con¬ 
tains  data  from  CS  safety  analysis  and  testing  ef¬ 
forts  but  also  contains  pertinent  hazard  and  causal 
factor  data  from  CSEs.  This  is  important,  as  one  of 
the  principles  of  CS  safety  is  an  assessment  of  over¬ 
all  CS  mishap  risk.  This  mishap  risk  assessment 
comprises  hazard  analysis  by  the  CS  safety  team  in 
conjunction  with  hazard  analysis  by  each  CSE  safe¬ 
ty  program  for  their  respective  CSE.  Potential  in¬ 
terface  hazards  and  causal  factors  are  assessed  by 
the  CS  safety  team  using  the  methodologies  dis¬ 
cussed  in  this  article.  In  addition  to  CS  and  CSE 
hazard  analysis,  CSE  software  causal  factors  must 
also  be  assessed  for  potential  contribution  to  CS 
mishap  risk.  Software  causal  factors  are  actual  CSE 
design  deficiencies  that  can  lead  to  the  realization 
of  a  CSE  hazard,  which  could  culminate  in  a  mis¬ 
hap.  If  the  CSE  hazard  has  relevance  to  a  CS  safety 


function,  then  the  CSE  software  causal  factor  likely 
has  relevance,  and  its  contribution  must  be  consid¬ 
ered  when  determining  CS  mishap  risk. 

In  order  for  a  CSE  to  make  an  informed  deter¬ 
mination  that  their  software  causal  factors  may  have 
CS  implications,  the  CS  safety  program  provides  the 
CSEs  with  CS  safety  functions,  hazards,  and  caus¬ 
al  factors  as  criteria.  CSEs  use  the  criteria  to  deter¬ 
mine  hazard  and  software  causal  factor  applicability 
in  response  to  CS  safety  “data  calls.”  Each  CSE  haz¬ 
ard  and  software  causal  factor  is  assessed  to  deter¬ 
mine  and  characterize  their  potential  CS  mishap 
risk  contribution.  For  CSE  software  causal  factors, 
the  CS  safety  team  assesses  each  risk  using  the  cri¬ 
teria  in  Table  1.  Each  CS  causal  factor  mishap  risk 
assessment  must  stand  on  its  own  in  defining  the 
potential  that  the  particular  causal  factor  could  lead 
to  the  mishap.  Each  CS  causal  factor  mishap  risk  as¬ 
sessment  is  discussed  and  arbitrated  at  the  CSSWG. 

In  addition  to  CS  software  causal  factor  mis¬ 
hap  risk  assessment,  CS  hazard  mishap  risk  as¬ 
sessments  are  performed  and  must  include  all 
associated  causal  factors  in  determining  the  poten¬ 
tial  that  a  particular  hazard  could  lead  to  a  CS  mis¬ 
hap.  The  aggregate  CS  mishap  risk  for  each  TLM 
considers  the  aggregate  of  all  associated  causal 


Table  1 .  Software  Causal  Factor  Risk  Criteria 


Mishap  Risk 
Level 

Description  of  Safety  Criteria 

HIGH 

-  A  software  implementation  or  software  design  defect  that: 

•  Leads  directly  to  a  catastrophic  or  critical  mishap,  or 

•  Subjects  the  system  to  a  single  point  (1 )  failure  that  would  lead  to  a  catastrophic  or 
critical  mishap 

SERIOUS 

-  A  software  implementation  or  software  design  defect  that: 

•  Influences  a  catastrophic  or  critical  mishap,  but  where  two  (2)  independent  functioning 
interlocks  or  human  actions  remain,  or 

•  Leads  directly  to  a  marginal  or  negligible  mishap 

MEDIUM 

-  A  software  implementation  or  software  design  defect  that: 

•  Influences  a  catastrophic  or  critical  mishap,  but  where  three  (3)  independent  functioning 
interlocks  or  human  actions  remain,  or 

•  Influences  a  marginal  or  negligible  mishap,  reducing  the  system  to  a  single  point  (1)  failure 

LOW 

-  A  software  implementation  or  software  design  defect  that: 

•  Influences  a  catastrophic  or  critical  mishap,  but  four  (4)  or  more  independent  functioning 
interlocks  or  human  actions  remain 

•  Would  be  a  causal  factor  for  a  marginal  or  negligible  mishap,  but  two  (2)  independent 
functioning  interlocks  or  human  actions  remain 

-  A  software  degradation  of  a  safety-critical  function  that  is  not 
categorized  as  high,  serious,  or  medium  safety  risk 

-  A  requirement  that,  if  implemented,  would  negatively  impact 
safety,  however  code  is  implemented  safely 
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Top-Level 
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Causal 
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MRI  =  IE  MRI  =  ID  MRI  =  1 E 

t  t  t  t 


3  System  1  (M) 

1  System  2  (L) 

2  System  3  (M) 


1  System  1  (L) 

2  System  2  (L) 

3  System  3  (M) 

1  System  4  (M) 

2  System  5  (M) 


No  Known 
Causal 
Factors  - 
Inherent  Risk 


3  System  1  (M) 
3  System  2  (L) 
2  System  3  (M) 
1  System  4  (M) 
1  System  5  (S) 
1  System  6  (M) 


3  System  1  (L) 

1  System  2  (L) 

1  System  3  (M) 

1  System  4  (M) 

2  System  5  (M) 

3  System  6  (M) 
1  System  7  (L) 


Mishap  Risk  Level 


L  =  Low  Mishap  Risk 


M=  Medium  Mishap  Risk 


S  =  Serious  Mishap  Risk 


Figure  3.  CS  Mishap  Risk  Assessment 


factors  and  hazards,  and  their  collective  potential 
for  mishap  as  illustrated  in  Figure  3. 

The  CS  TLM  assessment  is  the  potential  that 
the  mishap  will  occur  based  on  all  associated  haz¬ 
ards  and  causal  factors.  Using  the  example  depict¬ 
ed  in  Figure  3,  then,  each  software  causal  factor 
mishap  risk  assessment  is  performed  using  the 
criteria  in  Table  1,  and  shows  the  likelihood  that 
the  particular  causal  factor  could  lead  to  the  mis¬ 
hap,  referred  to  as  the  mishap  risk  level  (MRL).  So 
for  the  Hazard  Track  Mis-ID ,  there  are  five  Medi¬ 
um  Risk  and  one  Low  Risk  causal  factors.  These 
causal  factor  mishap  risk  assessments  reflect  the 
risk  that  the  mishap  of  Intercept  of  Friendly /N on- 
hostile  will  be  realized.  The  mishap  risk  associat¬ 
ed  with  the  hazard  Track  Mis-ID  reflects  the  risk 
based  on  CS  and  CSE  safety  hazard  analyses,  as 
well  as  the  mishap  risk  associated  with  the  caus¬ 
al  factor  mishap  risk  assessments.  In  this  case, 
the  mishap  risk  index  (MRI)  for  the  hazard  Track 
Mis-ID  is  considered  a  IE,  or  Medium  Risk ,  as  de¬ 
fined  in  the  Mishap  Risk  Assessment  Matrix  pro¬ 
vided  in  Figure  4. 

Determination  of  CS  Mishap  risk  takes  into 
consideration  the  aggregate  risk  of  each  hazard  that 
could  result  in  the  TLM.  Following  the  example  in 


Figure  3  again,  it  becomes  evident  that  there  are 
five  hazards  that  could  lead  to  the  TLM  Intercept  of 
Friendly /Nonhostile.  In  addition  to  Track  Mis-ID , 
the  four  other  hazards  and  their  MRIs  are: 

•  Failure/Inability  to  Terminate/Suspend  an 
Engagement  (MRI  =  IE  Medium  Risk) 

•  Failure  to  SCRAM  (MRI  =  ID  Serious  Risk) 

•  Tight/NOTACK/No  Fire  Zone  Errors  (MRI= 
ID  Serious  Risk) 

•  Erroneous/Inadvertent  Engagement  of  Track 
(MRI  =  IE  Medium  Risk) 

So  of  the  five  hazards  that  can  lead  to  the  TLM 
Intercept  of  Friendly /Nonhostile,  three  are  as¬ 
sessed  as  Medium  Risk ,  and  two  are  assessed  as  Se¬ 
rious  Risk.  These  mishap  risk  assessments  include 
the  results  of  CS  and  CSE  hazard  analysis,  as  well 
as  causal  factor  mishap  risk  assessments.  Note  that 
in  this  hypothetical  example,  there  are  no  known 
software  causal  factors  for  the  hazard  Failure  to 
SCRAM ,  so  the  hazard  mishap  risk  assessment  is 
based  on  CS  and  CSE  hazard  analysis  only.  Note, 
too,  that  in  this  example  the  overall  TLM  MRI  is 
1C  or  High  Risk.  An  explanation  for  this  may  be 
that,  in  the  judgment  of  the  CS  PFS,  the  probabili¬ 
ty  that  the  TLM  will  be  realized  increases  based  on 
the  two  Serious  hazard  mishap  risk  assessments  in 
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concert  with  the  Serious  Tight /NOTACK/No  Fire 
Zone  Errors  causal  factor  mishap  risk  assessment, 
and  the  fact  that  SCRAM  processing  is  likely  to  be 
exercised  during  tactical  operations.  This  exam¬ 
ple  is  to  be  used  only  to  illustrate  the  relationships 
between  causal  factor  mishap  risk  assessments  and 
how  they  are  a  part  of  the  hazard  mishap  risk  as¬ 
sessment  and  that,  taken  in  totality,  the  aggregate 
CS  TLM  risk  is  assessed. 

In  summary,  it  is  important  to  remember  that 
NAVSEAINST  8020. 6E  states  that  a  CS  safety  pro¬ 
gram  does  not  eliminate  the  need  for  CSE  safety 
programs  and  should  not  be  construed  as  reliev¬ 
ing  any  program  manager  (PM)  of  their  safety  pro¬ 
gram  responsibilities.  As  shown  in  this  article,  CS 
safety  programs  are  intended  to  be  executed  us¬ 
ing  integrated  hazard  assessment  methodologies, 
with  a  focus  on  identifying  and  resolving  hazards 


that  fall  outside  of  traditional  CSE  safety  program 
boundaries.  Some  of  the  benefits  of  a  well-executed 
CS  safety  program  include: 

•  End-to-end  CS  safety  assessment 

•  Enhanced  technical  communication  via  Na¬ 
vy-wide  CSSWG  meetings 

•  Coordinated  hazard  risk  assessments  and  re¬ 
porting  mechanisms 

•  Capability  for  providing  insight  into  CS  lev¬ 
el  issues  at  Mission  Readiness  Reviews,  Mis¬ 
sion  Control  Panels,  CS  Certification  Panels, 
and  other  major  milestone  events 

•  Consistent  CS  safety  approach  for  major 
program  managers  (MPMs) 

•  Consistent  CS-level  Software  System  Safe¬ 
ty  Technical  Review  Panel  (SSSTRP)  and 
Weapon  System  Explosives  Safety  Review 
Board  (WSESRB)  safety  reviews 


LOW  RISK 


Mishap  Risk 
Level  (MRL) 

Mishap  Risk 
Indices 

Acceptance  Authority 

High  Risk 

1  A,  IB,  1C,  2A, 
2B 

Component  Acquisition  Executive  (for  Navy 
programs,  this  is  the  Assistant  Secretary  of  the 
Navy  for  Research,  Development,  and 

Acquisition) 

Serious  Risk 

ID,  2C,  3A,  3B 

Program  Executive  Officer 

Medium  Risk 

IE,  2D,  2E,  3C, 
3D,  3E,  4A,  4B 

Program  Manager 

Low  Risk 

4C,  4D,  4E 

Figure  4.  Mishap  Risk  Assessment  Matrix 
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Shipboard  Combat  System  Training  Restoration 

By  Michael  Zemore ,  Rachael  Carroll ,  and  Brian  Schwark 


In  2004,  the  Program  Executive  Office  (PEO),  Integrated  Warfare  Systems  (IWS) 
restricted  the  use  of  Battle  Force  Tactical  Training  (BFTT)  at  sea  and  mandated  tagout 
of  all  weapon  delivery  systems  and  tracker  illuminators  (TIs)  in  response  to  safety  con¬ 
cerns.  In  an  effort  to  restore  this  critical  training  capability,  Naval  Surface  Warfare  Cen¬ 
ter,  Dahlgren  Division  (NSWCDD)  led  an  extensive  safety  evaluation  to  identify  the 
potential  hazards  associated  with  the  use  of  the  BFTT  system  and  other  combat  system 
training  capabilities  on  carriers  and  amphibious  assault  ships.  This  required  an  assess¬ 
ment  of  all  potential  safety  impacts  to  the  combat  system,  ship  control  systems,  air  con¬ 
trol  systems,  and  shipboard  equipment.  A  team  of  Dahlgren  safety  engineers  validated 
the  analytical  results  through  shipboard  verification  testing  and  collaboration  with  sub¬ 
ject  matter  experts  (SMEs)  from  the  Naval  Sea  Systems  Command,  the  Naval  Air  Sys¬ 
tems  Command,  the  Afloat  Training  Group,  and  the  U.S.  Fleet  Forces  Command.  The 
following  article  recounts  the  process  to  successful  completion  of  the  training  restora¬ 
tion  effort  and  authorization  to  restore  combat  system  training  with  BFTT  for  all  ships 
affected.  Also  included  is  a  discussion  of  the  lessons  learned  from  the  training  restora¬ 
tion  effort  and  how  this  knowledge  has  evolved  to  influence  both  engineering  process 
improvements  and  future  design  recommendations. 

In  the  late  1990s,  challenged  with  resource  reductions  to  support  fleet  training,  the 
U.S.  Navy  embarked  on  a  program  to  develop  a  robust  shipboard  combat  system  train¬ 
ing  capability.  The  BFTT  system  was  developed  to  meet  these  combat  system  training 
needs  for  individual  watchstanders,  ships  Combat  Information  Center  (CIC)  teams,  and 
battle  group  staffs.  The  BFTT  architecture  can  support  independent,  single-ship  training 
as  well  as  multiship  battle  group  training.  Battle  group  training  integrates  forces  by  uti¬ 
lizing  a  common  tactical  training  scenario  that  is  distributed  via  the  Navy  Continuous 
Training  Environment  (NCTE). 

The  shipboard  subsystem  training  capabilities  are  organic  and  designed  to  interface 
with  the  existing  onboard/embedded  trainer  configurations.  Because  the  BFTT  system 
wraps  around  the  combat  system,  stimulation/simulation  of  the  combat  system  is  trans¬ 
parent  to  the  trainees.  Once  safely  activated,  it  provides  the  essential  synthetic  data  to 
the  numerous  shipboard  systems  required  to  create  the  virtual  training  environment  in 
support  of  the  training  scenario  objectives.  To  establish  and  maintain  the  virtual  train¬ 
ing  environment,  BFTT  produces  and  supplies  synthetic  navigation  data  to  the  ships 
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navigation  distribution  system,  synthetic  track  de¬ 
tection  data  to  the  ships  radar,  and  synthetic  elec¬ 
tronic  warfare  emissions  data  to  electronic  warfare 
systems.  Collectively,  these  BFTT  capabilities  pro¬ 
vide  a  wide  spectrum  of  combat  system  training 
support,  thereby  reducing  underway  training  time 
and  off-ship  training  service  requirements. 

But  despite  the  benefits  associated  with  BFTT, 
subsequent  use  of  BFTT  was  halted  after  being 
linked  to  two  safety  incidents  that  occurred  dur¬ 
ing  combat  system  training.  The  first  shipboard  in¬ 
cident  was  reported  in  July  2004,  when  simulated 
navigation  data  was  distributed  to  a  ships  autopi¬ 
lot,  and  the  safety  of  ship  navigation  was  compro¬ 
mised.  Testing  at  Wallops  Island  and  shipboard 
uncovered  the  second  issue,  where  the  fire  control 
radar  was  unintentionally  commanded  to  radiate 
during  a  training  exercise.  As  a  result  of  these  in¬ 
cidents,  the  PEO  IWS  restricted  the  use  of  BFTT 
at  sea  and  directed  ships  to  tag  out  missile  launch¬ 
ers  and  fire  control  radars  when  conducting  BFTT 
training  in  port.  This  restriction  impacted  training 
for  guided  missile  cruisers  (CGs),  guided  missile 
destroyers  (DDGs),  aircraft  carriers  (CVs),  car¬ 
rier  vessels  nuclear  (CVNs),  amphibious  assault 
ships,  general  purpose  (LHAs),  amphibious  as¬ 
sault  ships,  multipurpose  (LHDs),  and  dock  land¬ 
ing  ships  (LSDs).  These  restrictions  were  mandated 
until  completion  of  a  safety  investigation  to  ensure 
that  all  conditions  for  potential  hazards— both  at 
sea  and  in  port— had  been  addressed. 

The  safety  investigation,  better  described  as  a 
detailed  systems  safety  engineering  analysis,  was 
assigned  to  safety  engineers  from  NSWCDDs 
Systems  Safety  Engineering  Division.  The  prima¬ 
ry  objective  was  to  restore  the  safe  use  of  BFTT  to 
the  surface  fleet  for  combat  system  training.  It  re¬ 
quired  a  focus  on  the  combat  system  training  de¬ 
signs,  configurations,  and  operational  procedures 
to  identify  potential  safety  issues  with  the  BFTT/ 
combat  system  integrated  training  capabilities. 
The  majority  of  the  investigation  and  systems  safe¬ 
ty  engineering  analyses  emphasized  the  carriers 
and  amphibious  assault  ships  configurations,  since 
Aegis  utilized  the  Aegis  Combat  Training  System 
with  its  embedded  safety  interlocks. 

The  analytical  effort  was  expected  to  be  com¬ 
plex,  given  the  numerous  BFTT  signal  injections 
within  the  combat  systems  and  ship  systems,  and 
the  uniqueness  of  the  installations  and  data  distri¬ 
bution  networks  across  individual  ships  and  ship 
classes.  The  initial  analytical  focus  was  to  fully 
identify  all  shipboard  systems  and  operations  that 
could  potentially  be  impacted  when  conducting 
combat  system  training.  This  initial  effort  helped 


formulate  the  path  forward  for  restoration  efforts 
and  provided  insights  for  the  Red  Team— an  in¬ 
dependent  group  tasked  to  perform  a  safety  and 
programmatic  review  of  the  BFTT.  The  Red  Team 
identified  eight  primary  areas  of  safety  concern  re¬ 
lated  to  combat  system  training  as  illustrated  in 
Figure  1. 

The  safety  evaluation  was  extensive  and  con¬ 
sidered  all  potential  hazards  associated  with  the 
combat  system,  ship  control  systems,  air  control 
systems,  and  shipboard  equipment.  The  effort  be¬ 
gan  with  data  gathering  and  verification  of  com¬ 
bat  system  element  (CSE)  information  for  safety 
evaluation.  This  included  collaboration  with  SMEs 
from  system  commands,  fleet  commanders,  afloat 
training  activities,  and  design  agents  to  understand 
and  characterize  all  potential  safety  issues.  Valida¬ 
tion  of  analytical  results  occurred  through  ship¬ 
board  verification  testing  and  collaboration  with 
SMEs.  All  safety  analysis  results  were  documented 
in  matrix  format  on  a  per  ship  basis.  This  allowed 
detailed  systems  safety  engineering  data  and  an¬ 
alytical  results  to  be  accurately  used  when  imple¬ 
menting  mitigations  for  each  impacted  ship. 

During  the  initial  assessment  of  intended 
BFTT  operational  uses,  it  was  clear  that  categoriz¬ 
ing  BFTT  utilization  as  the  binary  state  of  either 
££at  sea”  or  “in  port”  was  not  adequate  to  address  all 
potential  hazards.  Therefore,  the  team  defined  the 
operating  conditions  and  analytical  scope  to  spe¬ 
cifically  address  the  safe  use  of  BFTT  while  ships 
operate  pierside,  at  anchor,  underway,  and  during 
restricted  maneuvers.  Each  environment  changed 
the  conditions  of  the  analysis  and  the  resulting 
mitigations  for  safe  operation. 

The  analysis  encompassed  safety  assessment  of 
numerous  shipboard  systems  and  their  function¬ 
al  relationships  in  various  training  configurations. 
These  systems  were  analyzed  for  training- related 
hazards  associated  with  detailed  design,  physical 
interfaces,  system  modes,  embedded  training  capa¬ 
bilities,  moving  parts  and  energy,  power  up/down 
processes,  and  operator  interfaces.  The  systems  an¬ 
alyzed  were  those  associated  with  identification, 
engagement  control,  fire  control,  navigation,  sen¬ 
sor,  training,  data  extract,  and  communications. 
In  addition,  safety  devices,  verification  equipment, 
monitors,  nonstandard  configurations,  and  any¬ 
thing  else  identified  as  remotely  associated  with 
combat  system  training  was  included  in  the  analy¬ 
sis.  The  causal  factors  evaluated  included: 

•  Nonparticipating  embedded  trainer  being 
initiated 

•  Participating  embedded  trainer  being  de-en¬ 
ergized 
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Figure  1.  Primary  Safety  Concerns 


•  Nonparticipating  CSE  being  energized 

•  Participating  CSE  being  de-energized 

•  Mixed  CSE  modes 

•  Maintenance  procedures  being  conducted 
during  training 

•  Incomplete  training  documentation 

•  Mixed  tagging  of  tracks  (training/tactical) 

The  culmination  of  the  analysis  effort  and  the 

process  for  implementing  mitigations  to  restore  the 
use  of  BFTT  required  a  detailed  review  of  the  safe¬ 
ty  analyses  and  mitigations  by  the  Weapon  System 
Explosives  Safety  Review  Board  (WSESRB).  Char¬ 
tered  by  the  Chief  of  Naval  Operations  (CNO) 
to  provide  independent  oversight  of  the  Depart¬ 
ment  of  the  Navy  (DON)  weapon  programs  safe¬ 
ty  efforts,  the  WSESRB  also  provides  safety-related 
guidance  and  recommendations  regarding  safe¬ 
ty  engineering  analyses,  hardware/software/sys- 
tem  designs,  and  hazard  mitigation  strategies  for 
DON  weapon-related  systems.  Given  the  complex¬ 
ity  of  the  analyses  and  volume  of  systems  safety  en¬ 
gineering  data,  multiple  WSESRB  review  sessions, 
collaborations,  and  interactions  were  required  to 
incrementally  gain  approvals  to  restore  surface 
ship  BFTT  training  capability 

The  mitigations,  implemented  as  mandated 
procedures,  lowered  the  risk  of  possible  mishap 
during  combat  system  training.  Lifting  the  weap¬ 
on  delivery  system  and  TI  tagouts  allowed  all  nec¬ 
essary  components  to  be  included  for  end-to-end 
combat  system  training  exercises.  The  procedural 


mandates  were  written  as  supplements  to  existing 
Combat  System  Operational  Sequencing  System 
(CSOSS)  guidance.  This  documentation  clearly  de¬ 
lineated  necessary  setup  procedures,  restrictions, 
cautions  and  warnings,  and  post-training  saf- 
ing  procedures  to  maintain  shipboard  and  weap¬ 
on  system  safety  for  all  aspects  of  BFTT  integrated 
and  stand-alone  training  events.  The  effort  culmi¬ 
nated  with  the  authorization  to  regain  use  of  the 
BFTT  and  stand-alone  trainers  while  lifting  weap¬ 
on  delivery  system  and  TI  tagout  restrictions  for 
all  ships.  This  authorization  was  predicated  on  the 
implementation  of  hull- specific  hazard  mitigations 
as  derived  from  the  safety  analyses.  Realistic  com¬ 
bat  system  training  is  inherently  dangerous  when 
conducted  shipboard  with  actual  weapon  systems. 
Restoration  of  the  safe  combat  system  training  ca¬ 
pability  allows  for  improved  competencies  and 
mission  readiness  of  our  warfighters. 

This  safety  study  underscored  the  necessi¬ 
ty  for  programs  to  dedicate  resources  to  execute 
system  safety  activities  with  a  system -of- systems 
perspective.  Or  consider — this  safety  study  un¬ 
derscored  the  reason  why  dedicated  resources  are 
necessary  to  execute  system  safety  activities  with 
a  system-of-systems  perspective.  Significant  pro¬ 
cess  improvements  initiated  as  a  result  of  this  ef¬ 
fort  continue  to  reap  benefits  today.  For  training 
systems,  as  with  tactical  systems,  programs  must 
integrate  systems  safety  engineers  with  the  oth¬ 
er  functional  areas  and  working  groups.  It  is  also 
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critical  that  safety  programs  for  individual  CSEs 
are  well  integrated  with  the  overall  combat  system 
safety  programs,  and  are  active  in  system  safety 
working  groups.  These  relationships  and  forums 
help  ensure  that  integrated  combat  system  train¬ 
ing  safety  concerns  are  identified  early,  discussed 
among  the  SMEs,  and  tracked  through  resolution. 

At  the  heart  of  systems  safety  engineering  is 
the  objective  to  positively  influence  system  de¬ 
sign  to  minimize  reliance  on  human  actions  for 
safe  operation.  The  combat  system  training  resto¬ 
ration  safety  team  noted  design  concerns  through¬ 
out  the  analysis  and  documented  recommended 
architectural  considerations  for  future  training  ca¬ 
pabilities  in  the  Navys  Training  Safety  Precepts  and 
Design  Requirements.  The  publication,  developed 
by  NSWCDD  in  partnership  with  the  Naval  Ord¬ 
nance  Safety  and  Security  Activity,  should  give  the 
guiding  principles  for  every  organization  that  will 
provide  a  system  or  embedded  capability  to  sup¬ 
port  combat  system  training.  A  high-level  sum¬ 
mary  of  some  key  points  detailed  in  the  Training 
Safety  Precepts  and  Design  Requirements  follows: 

•  Future  training  capabilities  should  be  en¬ 
gineered  to  be  reconfigurable,  predictable, 
controllable,  scalable,  and  interoperable. 

•  It  is  important  to  have  safety  in  layers:  em¬ 
bed,  automated  safety  interlocks  for  mode 
transitions  in  each  participating  system,  with 
verification  processing  across  all  interfaces. 

•  Simplify  and  automate  training  transitions 
through  safe  operating  modes  to  reduce  po¬ 
tential  safety  risks  of  sharing  mixed-mode 
data. 
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•  Localize  and  automate  positive  control  and 
monitoring  of  the  training  configuration  for 
all  participating  ship  systems. 

•  Design  integrated  systems  to  ensure  that  tac¬ 
tical  operations  can  be  safely  maintained 
when  training  events  are  being  conducted. 

•  Eliminate  mixed-mode  operation;  ensure 
that  all  training  data  is  properly  tagged,  and 
that  all  systems  with  the  potential  to  accept 
training  data  are  designed  to  process  the 
training  tags. 

•  Display  a  positive  visual  indication  of  train¬ 
ing  mode  on  all  consoles,  including  all  sys¬ 
tem  displays  associated  with  training/ 
simulated  data. 

•  Design  the  entire  integrated  training  ca¬ 
pability  to  fleet  requirements  via  a  system- 
of-systems  approach.  Simply  engineering  a 
“box”  that  interfaces  with  an  existing  design 
is  not  adequate. 

The  significant  lesson  learned  during  the 
3 -year  effort  to  restore  full  BFTT  training  ca¬ 
pability  to  the  fleet  was  the  recognition  that  in¬ 
troducing  new  or  enhanced  shipboard  training 
functionality  or  capabilities  requires  the  same, 
or  greater,  engineering  rigor  as  that  expended  for 
changes  to  shipboard  tactical  systems.  This  lesson 
learned  must  be  embraced  and  acted  upon  by  all 
of  the  fleet  training  stakeholder  activities— tech¬ 
nical  and  operational— to  ensure  that  the  neces¬ 
sary  engineering  requirements,  including  safety, 
are  accomplished  across  the  complex  system-of- 
systems  enterprise  that  compose  a  ships  combat 
system  training  capability. 
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This  article  is  an  examination  of  total  ship  safety  discussing  the  combination  of 
dangerous  substance  handling  and  storage,  fire  prevention  and  fighting,  and  electro¬ 
magnetic  environmental  effects  (E3).  The  authors  use  an  assessment  of  motor  gasoline 
(MOGAS)  handling  and  storage  on  a  Navy  combatant  as  an  example  of  the  coordinated 
efforts  of  system  safety  with  various  technical  warrant  holders  (TWHs)  in  order  to  pro¬ 
vide  a  safe  system  to  the  U.S.  Navy,  with  known  risks  identified  and  assessed. 

Total  ship  safety  is  an  approach  that  provides  a  ship  acquisition  program  manag¬ 
er  with  an  understanding  of  the  comprehensive  safety  risk  inherent  in  the  ship  and 
associated  systems— from  bow  to  stern— and  from  the  top  of  the  mast  to  the  keel. 
Throughout  the  development  of  the  ship,  the  safety  engineer  is  continuously  perform¬ 
ing  analyses  to  assess  the  safety  of  design  and  identify  potential  hazards  and  design 
mitigations,  as  well  as  communicating  safety  risk  status  to  the  program  office.  Many 
times  the  ship  safety  assessments  focus  on  specific  operations  to  determine  safety  risk 
inherent  in  those  operations,  as  was  the  case  in  a  recent  safety  assessment  for  MOGAS 
stowage  on  an  L-class  ship. 

The  use  of  MOGAS  has  led  to  incidents  involving  fatalities  aboard  Navy  ships 
in  the  past;  thus,  the  Navy  has  minimized  the  use  of  MOGAS  at  sea  due  to  the  in¬ 
herent  safety  risks.  However,  although  many  systems  use  fuels  that  are  less  sensitive 
to  ignition,  such  as  diesel  marine  and  JP-5  jet  fuel,  MOGAS  is  still  required  for  cer¬ 
tain  equipment  that  supports  special  operations  forces,  deployed  Marines,  and  certain 
shipboard  systems. 

MOGAS  has  a  flash  point,  which  is  the  lowest  temperature  where  enough  fluid  can 
evaporate  to  form  a  combustible  concentration  of  gas,  of  -45°F.  By  comparison,  diesel 
fuel  (1-D)  has  a  flash  point  of  100°F.  The  U.S.  Navy  has  implemented  a  program  to  elim¬ 
inate  the  need  for  MOGAS  by  modifying  systems,  such  as  aircraft  using  aviation  gas¬ 
oline  (AVGAS)  and  the  P250  submersible  pump,  to  operate  with  JP-5.  However,  there 
remains  a  need  to  provide  MOGAS  for  support  operation  of  equipment  deployed  with 
embarked  forces.  In  1993,  the  Commandant  of  the  Marine  Corps,  via  CMC  letter  5000 
EPB-12  of  29  July  1993,  endorsed  a  minimum  MOGAS  stowage  requirement  of  10,000 
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gallons  for  embarked  Marine  expeditionary  units 
(MEUs).  To  date,  this  requirement  to  transport  and 
deploy  MOGAS  remains. 

The  Systems  Safety  Engineering  Division  of 
the  Naval  Surface  Warfare  Center,  Dahlgren  Divi¬ 
sion  (NSWCDD)  recently  completed  a  safety  as¬ 
sessment  of  MOGAS  stowage  for  an  L-class  ship. 
The  ship  had  a  requirement  to  provide  stowage  for 
3,000  gallons  of  MOGAS  for  internal  storage  and 
fuel  transfer.  The  Naval  Sea  Systems  Command 
(NAVSEA)  design  community  met  on  the  ship  to 
inspect  the  internal  fuel  stowage  and  fuel  transfer 
spaces,  and  to  discuss  the  issues  with  internal  stow¬ 
age/fuel  transfer  and  its  potential  safety  risk.  As  a 
result  of  their  discussion,  several  changes  were  im¬ 
plemented  to  reduce  the  risk  of  MOGAS  aboard 
ship,  including: 

•  Reduce  the  total  onboard  stowage  of  MOGAS 
from  3,000  gallons  to  330  gallons 

•  Abandon  all  internal  stowage  of  MOGAS, 
including  both  the  MOGAS  Stowage  Room 
and  MOGAS  Transfer  Room 

•  Remove  the  external  1,500-gallon  bladder 
stowage  rack  and  replace  with  modified  low- 
sulfur  diesel  (LSD)  MOGAS  racks  (55-gal- 
lon  drum  type) 

•  Install  modified  LSD-type  MOGAS  jettison 
locker  for  small  bladders  and  jerry  cans 

•  Install  aqueous  firefighting  foam  (AFFF) 
fixed  sprinkling  to  the  external  MOGAS 
stowage  area 

•  Modify  and  issue  an  instruction  to  reflect 
ship  material  and  operation¬ 
al  requirements  affected  by 
this  change 

The  MOGAS  stowage  system 
for  the  six  55 -gallon  drums  is  a 
relatively  simple  “strap -on”  sys¬ 
tem  that  was  determined  to  be  ad¬ 
equate  for  this  ship.  The  system 
consists  of  rack- system  hardware, 
including  two  jettison  racks  locat¬ 
ed  amid  ship,  on  the  01  level  on 
the  port  side  deck  edge.  One  rack 
holds  six  55-gallon  drums  and  the 
other,  a  MOGAS  stowage  locker 
that  is  adjacent  to  the  drum  rack 
and  used  to  store  equipment  and 
containers,  including  fuel  bladders 
and  jerry  cans.  The  locker  stores 
equipment  and  used  fuel  bladders 
and  containers,  which  may  be  par¬ 
tially  filled  or  empty  and  are  con¬ 
sidered  hazardous;  see  Figures  1 
and  2. 


The  system  is  designed  for  manual  emergency 
jettison  of  the  six  5 5 -gallon  drums  and  the  storage 
locker  in  the  event  of  a  fire.  When  the  jettison  sys¬ 
tem  is  activated,  restraining  bolts  are  released,  and 
the  drums  and  locker  roll  overboard.  The  drum 
system  and  locker  have  separate  activation  levers. 

A  safety  assessment  was  conducted  to  deter¬ 
mine  the  associated  safety  risk  of  shipboard  MO¬ 
GAS  stowage.  NSWCDD  Platform  Safety  Branch 
personnel  conducting  the  safety  assessment  were 
part  of  the  ship  inspection  team  and  developed  the 
safety  assessment  after  discussions  with  the  ship 
designers,  ships  crew,  and  applicable  Navy  TWHs. 
The  ship  areas  and  equipment  pertinent  to  this  as¬ 
sessment  included  the  flight  deck,  vehicle  deck, 
well  deck,  and  boat  crane. 

MOGAS  is  prepared  for  deployment  for  the 
MEU  by  transferring  fuel  from  the  55-gallon  drums 
to  fuel  bladders  or  jerry  cans.  These  containers  are 
moved  to  the  deployment  vehicles  via  a  transport 
route  that  traverses  topside  areas,  a  cargo  elevator, 
the  vehicle  deck,  and  then  either  the  well  deck  or 
the  flight  deck  for  embarkation  by  the  MEU.  MO¬ 
GAS  may  also  be  transferred  to  boats  alongside  the 
ship  using  the  boat  crane.  The  drums  may  be  trans¬ 
ferred  to  boats  only  by  using  the  boat  crane;  they 
are  not  allowed  to  be  moved  internally  through 
the  ship.  All  the  equipment  used  to  transfer  fuel 
is  kept  in  the  locker,  including  the  tools.  The  up¬ 
per  three  drums  in  the  jettison  rack  are  for  storage 
only.  If  MOGAS  is  required  from  them,  they  must 


Figure  1.  Shipboard  MOGAS  Rack  Storage  System 
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be  swapped  out  with  the  lower  three  drums,  using 
the  provided  J-davits. 

The  drums  and  the  stowage  locker  may  be 
manually  jettisoned  during  a  fire,  and  a  manual¬ 
ly  operated  AFFF  fire-suppression  system  activated 
to  provide  onboard  fire  protection  for  the  MOGAS 
storage  area.  In  the  event  of  a  fire  in  the  storage 
area,  personnel  would  need  to  manually  jettison 
both  the  drums  and  lockers,  and  activate  the  AFFF 
system.  The  activation  mechanisms  are  located  in 
the  boat  valley. 

Use  of  MOGAS  on  Navy  ships  presents  the  po¬ 
tential  hazard  of  a  shipboard  fire,  exposure  of  per¬ 
sonnel  to  hazardous  chemicals  and  vapors,  and  may 
impact  the  environment.  The  safety  assessment  for 
use  of  MOGAS  on  the  L-class  ship  addressed  each 
of  these  areas  for  each  potential  mishap.  Because 
a  fire  requires  only  fuel,  oxidizer,  and  an  ignition 


source  to  burn,  the  safety  assessment  focused  on 
the  ignition  source  and  fuel  in  assessing  mishap 
potential  during  operations. 

The  assessment  considered  potential  ignition 
sources  such  as  hot  work,  sparks,  smoking,  pyro¬ 
technic  devices,  weather  conditions,  and  radiation 
hazards.  Control  of  ignition  sources  during  ship 
operations  can  be  addressed  by  isolating  hot  work 
from  the  fuel  sources,  preventing  smoking  adja¬ 
cent  to  potential  fuel  sources,  controlling  the  use 
of  pyrotechnic  devices,  ensuring  proper  ground¬ 
ing  in  the  event  of  inclement  weather,  and  identify¬ 
ing  and  controlling  sources  of  ignition  from  ships 
radars  and  antennas.  Directly  related  to  the  threat 
of  mishap  during  MOGAS  operations  are  the  tools 
that  are  used  during  those  operations.  Safety  en¬ 
gineering  personnel  noted  that  the  use  of  non¬ 
sparking  tools  eliminates  an  ignition  source  during 
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MOGAS  operations  of  fuel  transfer  from  a  drum  to 
a  bladder  or  jerry  can.  The  potential  for  an  ignition 
source  due  to  ships  radars  and  antennas  also  re¬ 
quired  a  survey  to  determine  the  radiation  hazards. 
A  credible  radiation  hazard  from  this  assessment  is 
the  existence  of  radiating  emitters  that  create  haz¬ 
ardous  contact  currents  on  the  boat  crane  hook.  In 
addition,  the  assessment  considered  other  ignition 
sources,  such  as  nonexplosion-proof  light  and  elec¬ 
trical  fixtures. 

Aside  from  combustion,  two  other  possible 
mishaps  are  exposure  of  personnel  to  toxic  vapors 
and  impact  to  the  environment  resulting  from  a 
spill.  Mitigations  are  divided  into  hazard  mitiga¬ 
tions  and  mishap  mitigations.  Hazard  mitigations 
are  designed  to  prevent  hazards  from  developing 
into  mishaps.  Mishap  mitigations  reduce  the  effect 
of  a  mishap  once  an  event  has  been  initiated.  The 
hazard  mitigations  for  the  MOGAS  system  include 
minimizing  the  quantity  of  MOGAS  stored  and 
handled,  transfer  of  MOGAS  bladders  and  jerry 
cans  in  Tri-Wall  containers,  the  use  of  nonspark¬ 
ing  tools,  and  the  use  of  approved  containers,  such 
as  55-gallon  drums,  6-gallon  bladders,  18-gallon 
bladders,  and  jerry  cans. 

Mitigations  to  mishaps  from  MOGAS  stor¬ 
age,  handling,  and  transport  were  assessed  to  de¬ 
termine  their  impact  to  the  ship  personnel,  ship 
equipment,  and  the  environment.  Mishap  mitiga¬ 
tions  include  the  following: 

•  The  use  of  AFFF  in  the  storage  area  to  pro¬ 
vide  fire  suppression 

•  Readily  available  hazardous  material  spill 
kits  in  the  storage  areas  and  along  the  trans¬ 
port  routes 

•  Use  of  personal  protective  equipment  (PPE) 
during  fuel  handling  operations 

•  Installation  of  explosion-proof  lights  and 
fans  in  the  storage  areas  and  fuel  transport 
routes 

•  Proper  training  for  ship  damage  control 

•  Use  of  Tri-Wall  containers  for  transport  of 
bladders  and  jerry  cans  internal  to  the  ship 
and  jettison  of  MOGAS  drums  and  stowage 
locker  when  the  storage  area  is  threatened 
by  fire 

From  these  analyses,  the  system  safety  team 
determined  that  the  highest  risk  operation  to  the 
ship  was  transferring  bladders  and  jerry  cans  with¬ 
in  the  interior  of  the  ship.  Fuel  spills  that  occur 
during  transfer  will  present  explosive  vapors  and 
severe  fire  hazards.  It  was  noted  that,  along  the 
transfer  route,  there  are  nonexplosion-proof  fix¬ 
tures  and  outlets.  It  was  also  noted  that  the  ven¬ 
tilation  systems  in  the  vehicle  deck  and  well-deck 


areas  are  designed  to  vent  JP-5  fumes.  It  was  not 
known,  however,  if  the  current  system  configura¬ 
tion  would  be  effective  for  MOGAS  vapors.  MO¬ 
GAS  fumes  are  heavier  than  air  and  may  settle  in 
lower  decks  away  from  the  spill  area.  All  these  ar¬ 
eas  should  have  explosion-proof  fixtures.  The  ship 
procedures  clearly  state  that  no  transfer  of  55-gal- 
lon  drums  (either  full  or  empty)  are  allowed  in  the 
interior  of  the  ship,  thus  reducing  the  likelihood 
of  a  large  internal  spill  due  to  a  catastrophic  drum 
failure. 

Several  factors  were  identified  in  the  assess¬ 
ment  that  would  mitigate  the  associated  safety 
hazards  from  MOGAS  storage,  transfer,  and  move¬ 
ment  about  the  ship.  Minimizing  the  amount  of 
MOGAS  involved  during  transfer  is  essential.  The 
use  of  Tri-Wall  containers  to  transport  fuel  blad¬ 
ders  and  jerry  cans,  while  forbidding  the  transport 
of  5 5 -gallon  drums  interior  to  the  ship,  mitigates 
potential  risk  from  large,  uncontained  fuel  spills. 
Identifying  potential  ignition  sources— such  as  an¬ 
tennas/emitters,  explosion-proof  electrical  outlets 
and  light  fixtures,  using  nonsparking  tools,  and  im¬ 
plementing  proper  controls— all  help  to  mitigate 
the  potential  for  initiating  a  fire. 

The  location  of  the  storage  racks  and  the  ability 
to  remotely  jettison  them  are  two  means  of  remov¬ 
ing  the  fuel  source  in  the  event  of  an  adjacent  fire. 
The  storage  area  is  also  provided  with  AFFF  fire 
suppression.  Mishaps  resulting  in  contamination 
of  personnel  and  the  environment  were  assessed, 
and  the  threat  was  considered  negligible  due  to  the 
relatively  small  amount  of  MOGAS  that  may  leak. 
Personnel  must  be  equipped  with  the  proper  PPE 
to  mitigate  the  potential  for  severe  injury.  Because 
transfer  of  MOGAS  from  the  drums  to  fuel  blad¬ 
ders  is  conducted  in  an  unconfined,  open  area,  the 
personnel  exposure  to  hazardous  vapors  is  con¬ 
sidered  minimal.  Residual  spillage  during  these 
operations  should  be  insignificant  and  result  in  a 
minimal  environmental  impact.  When  the  lower 
three  drums  are  empty,  they  are  swapped  out  with 
the  upper  three  drums  using  two  J-davits.  Opera¬ 
tions  that  require  moving  fuel  containers  from  the 
storage  location  to  boats  alongside  the  ship  should, 
therefore,  be  low  risk  to  the  platform,  since  the 
ships  boat  crane  will  be  used. 

While  stowage  and  transportation  of  this  high¬ 
ly  combustible  and  inherently  dangerous  substance 
aboard  U.S.  Navy  ships  has  been  minimized,  it  can¬ 
not  at  this  point  be  eliminated.  The  application  of 
focused  analysis  utilizing  system  safety  principles, 
however,  allows  a  reduction  in  mishap  risk  to  a  lev¬ 
el  at  which  the  benefit  to  the  warfighter  is  com¬ 
mensurate  or  greater  than  the  risk  itself. 
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Implementation  of  Pointing 
and  Firing  Cutout  Zones 


By  David  Morgan  and  Greg  Sellers 


Properly  designed  and  implemented  pointing  and  firing  cutout  (P&FCO)  zones— 
also  known  as  no  point/no  fire  (NPNF)  zones— are  essential  for  the  safe  use  of  trainable 
guns  and  missile  launchers  aboard  U.S.  Navy  ships.  P&FCO  zones  protect  a  ships  struc¬ 
ture  from  damage  due  to  the  use  of  weapon  systems,  while  also  providing  the  weapon 
systems  with  the  maximum  coverage  possible.  P&FCO  zones  are  designed  for  missile 
systems  and  major-caliber  guns  by  the  Naval  Surface  Warfare  Center,  Dahlgren  Divi¬ 
sion  (NSWCDD),  in  accordance  with  NAVSEAINST  9700.2,  Integrated  Topside  Safety 
and  Certification  Program  for  Surface  Ships ,  September  1998.  This  article  will  discuss  the 
various  ways  P&FCO  zones  can  be  implemented  and  the  positive  and  negative  charac¬ 
teristics  associated  with  each  implementation  strategy. 

In  the  days  of  gun  ports,  P&FCO  zones  were  unnecessary  because  the  barrel  of  the 
cannon  was  outboard  of  the  ship,  and  the  cannon  could  not  be  turned  enough  such  that 
it  ever  pointed  at  a  ships  structure.  Furthermore,  the  sailor  would  look  out  the  port  and 
not  fire  the  cannon  until  the  target  lined  up  with  it;  that  situation  no  longer  exists.  Weap¬ 
on  systems  can  be  landed  anywhere  on  a  ships  topside,  and  given  their  flexibility  in 
pointing,  they  have  ample  potential  to  fire  into  a  ships  structure.  To  make  matters  worse, 
they  are  aimed  at  targets  by  computers  that  are  tracking  the  selected  targets  but  not  the 
interfering  aspects  of  a  ships  structure.  Hence,  the  concept  of  P&FCO  zones  was  born. 

The  simplest  implementation  of  P&FCO  zones  that  is  used  today  is  for  machine 
guns  along  deck  edges.  Physical  hard  stops  prevent  the  guns  from  pointing  too  far  to  ei¬ 
ther  side  (train  or  bearing)  or  down  (elevation),  and  the  amount  of  travel  allowed  is  dic¬ 
tated  by  an  adjacent  ships  structure.  If  you  cannot  point  at  it,  you  cannot  shoot  into  it. 
Old-style  train  hard  stops  are  machined  and  then  bolted  into  place.  Newer  train  hard 
stops  and  the  elevation  hard  stop  are  adjusted  by  turning  a  bolt.  This  style  of  P&FCO 
zone  gives  the  weapon  a  rectangle  within  which  it  can  operate. 

If  a  weapon  system  is  not  on  the  deck  edge,  or  if  firing  over  a  low  ship  structure  at 
one  point  without  losing  a  lower  elevation  firing  angle  at  another  point  is  required,  a 
simple  rectangular  P&FCO  zone  is  unacceptable.  What  is  needed  is  the  ability  to  imple¬ 
ment  a  contoured  P&FCO  zone.  In  a  world  where  cost  is  no  object,  this  contoured  zone 
boundary  would  be  a  free-form  curve  that  the  weapon  system  would  follow  as  it  barely 
cleared  all  ship  structure.  In  practice  today,  however,  contours  are  made  up  of  horizon¬ 
tal  and  vertical  line  segments. 


108 


Naval  Sea  Systems  Command 


Implementation  of  Pointing 
and  Firing  Cutout  Zones 


For  many  years,  the  accepted  method  of  im¬ 
plementing  P&FCO  zones  was  through  the  use 
of  two  stacks  of  mechanical  cams:  one  stack  con¬ 
trolling  train  and  another  controlling  elevation. 
(Some  readers  may  remember  that  in  the  past,  the 
P&FCO  design  function  was  performed  by  the 
NSWCDD  Cams  Group.)  The  train  stack  rotates 
with  the  weapon  in  train,  and  the  elevation  stack 
turns  as  the  weapon  moves  up  and  down.  These 
stacks  of  cams  are  paired  with  roller  switches  that 
rest  against  their  outside  surface.  The  outside  sur¬ 
faces  of  the  cams  themselves  are  machined  so  that 
they  have  a  lobe  along  a  certain  length  of  arc.  As 
the  weapon  moves,  the  cams  move  under  the  roll¬ 
er  switches,  and  as  the  roller  switches  go  on  and  off 
the  lobes,  firing  circuits  are  enabled/disabled. 

The  only  remaining  systems  in  the  U.S.  Navy 
using  a  cam  system  are  the  5-inch/54-caliber  gun 
aboard  older  guided  missile  destroyers  (DDGs) 


and  most  guided  missile  cruisers  (CGs),  and  the 
76mm  gun  aboard  guided  missile  frigates  (FFGs). 
The  5-inch/ 54-caliber  gun  has  four  elevation  cams: 
one  controlling  the  upper  and  lower  firing  limits 
and  the  other  three  allowing  for  three  intermediate 
elevation  limits.  The  elevation  cams  are  paired  off 
with  train  cams  that  define  the  extent  of  each  inter¬ 
mediate  elevation  limit.  Actually,  two  lobes  can  be 
machined  onto  each  train  cam,  so  that  firing  cutout 
(FCO)  zone  design  can  have  two  separate  areas  at 
the  three  different  heights.  The  bottom  line  is  that 
all  of  the  structure  has  to  fit  under  these  three  ele¬ 
vation  limits,  which  makes  designing  zones  an  ex¬ 
ercise  in  trade-offs.  Pointing  limits  define  a  simple 
rectangle,  and  are  implemented  by  adjusting  elec¬ 
tric  pots.  A  5-inch/54  cam  with  one  lobe  is  shown 
in  Figure  1  and  a  typical  5-inch/54  FCO  zone  de¬ 
sign  in  Figure  2.  This  particular  design  was  imple¬ 
mented  with  three  one-lobe  train  cams. 

The  76mm  gun  system  is  similar,  but 
it  allows  four  elevation  limits.  A  fifth  el¬ 
evation  cam  is  used  to  define  where  the 
elevation  motor  will  shut  down,  effective¬ 
ly  serving  as  a  backup  pointing  limit.  The 
primary  elevation  pointing  limits  are  ad¬ 
justed  by  using  different  value  resistors. 
This  gun  has  no  train  pointing  limits;  it 
can  rotate  360°.  A  76mm  gun  P&FCO  cam 
with  two  lobes  is  shown  in  Figure  3,  and 
a  typical  P&FCO  zone  design  is  shown  in 
Figure  4.  This  zone  was  implemented  with 
single-lobed  cams. 

The  other  remaining  mechanical  FCO 
system  found  in  the  U.S.  Navy  is  used 
by  the  Phalanx  Close-In  Weapon  Sys¬ 
tem  (CIWS).  CIWS  incorporates  stacks 
of  microswitches,  two  each  for  train  and 
elevation.  Each  stack  contains  four  micro¬ 
switches.  The  enable  and  disable  points 
for  each  microswitch  can  be  adjusted 
using  an  Allen  wrench.  Each  elevation 
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Figure  1.  MK  45  Gun  FCO  Cam 


Figure  2.  Typical  5-inch/54  Gun  FCO  Zone 
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switch  is  paired  with  a  train  switch,  and 
each  pair  defines  a  rectangle.  Seven  of 
these  rectangles  define  an  area  where 
firing  is  allowed;  their  overlay  defines 
the  overall  firing  zone.  The  remaining 
rectangle  defines  an  area  where  firing  is 
not  allowed  and  its  activation  results  in 
an  FCO  “pop-up”  over  moveable  equip¬ 
ment.  CIWS  pointing  limits  are  defined 
by  hard  stops  and  are  not  adjustable. 
A  switch  stack  is  shown  in  Figure  5.  A 
typical  CIWS  FCO  zone  is  shown  in 
Figure  6,  and  its  corresponding  sector 
diagram  (excluding  Sector  8)  is  shown 
in  Figure  7. 

As  one  might  expect,  over  time, 
mechanical  cutout  systems  can  drift 
outside  specifications;  parts  wear  down, 
loosen,  or  become  out  of  adjustment. 
Given  the  large  number  of  mechanical 
parts  these  systems  employ,  the  main¬ 
tenance  requirements  are  significant 
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Figure  3.  76mm  Gun  FCO  Cam 


Figure  4.  Typical  76mm  Gun  FCO  Zone 


and  require  personnel  with  the  appropriate  ex¬ 
pertise  and  skill  set  to  bring  the  components  back 
into  compliance  with  specifications.  The  use  of  cir¬ 
cuit  boards  containing  information  programmed 
onto  a  chip  on  a  circuit  card  to  implement  P&FCO 
zones  was  the  logical  progression  to  alleviate  the 
maintenance  burden  of  mechanical  parts.  This  ap¬ 
proach  is  well  represented  by  the  North  Atlantic 
Treaty  Organization  (NATO)  Seasparrow  Missile 
System  (NSSMS).  This  system  is  a  digital  imple¬ 
mentation  of  the  analog  systems  in  the  5-inch/54- 
and  76-mm  guns,  where  just  four  elevation  values 
are  allowed  in  the  FCO  zone  design.  A  digital  twist 
is  that  the  pointing  cutout  values  are  derived  from 
the  FCO  values.  Although  the  maintenance  is¬ 
sues  associated  with  the  mechanical  FCO  systems 
are  eliminated,  flexibility  in  zone  design  is  not  im¬ 
proved  at  all.  Additionally,  there  is  a  logistical  issue 


introduced;  if  the  card  goes  bad,  there  is  nothing 
that  can  be  repaired.  The  circuit  card  must  be  re¬ 
placed.  To  alleviate  this  issue  for  deployed  ships, 
spares  containing  the  same  information  are  pro¬ 
vided  to  ships.  A  minor  step  forward  for  NSSMS 
was  achieved  with  NSSMS  Mod  12  and  13  systems, 
where  the  P&FCO  information  is  now  written  to 
the  same  media  as  used  for  digital  cameras.  An 
NSSMS  P&FCO  board  is  shown  in  Figure  8,  and 
a  typical  NSSMS  FCO  zone  is  shown  in  Figure  9. 

A  major  step  forward  in  P&FCO  zone  im¬ 
plementation  was  achieved  in  the  Rolling  Air¬ 
frame  Missile  (RAM)  launcher.  While  this  system 
also  uses  a  programmed  circuit  board,  the  input 
file  is  a  table  of  256  elevation  values  in  1.4°  train 
steps.  While  in  earlier  systems  the  number  of  steps 
in  the  FCO  zone  design  was  limited  by  the  FCO 
zone  mechanism,  this  limitation  does  not  exist  in 
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Figure  5.  CIWS  Switch  Stack 


Figure  6.  Typical  CIWS  FCO  Zone 


Figure  7.  Sectors  Defining  CIWS  FCO  Zone 
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Figure  8.  NSSMS  FCO  Circuit  Card 


Figure  9.  Typical  NSSMS  FCO  Zone 


RAM.  In  fact,  the  mechanics  of  launcher  motion 
is  the  limiting  factor  in  zone  design,  and  steps  as 
small  as  5.6°  are  allowed.  As  a  result,  many  more 
steps  are  possible,  as  well  as  much  more  flexibility. 
The  only  negative  to  this  approach  is  that  occasions 
arise  where  one  would  like  to  implement  a  step  val¬ 
ue  that  does  not  correspond  to  a  multiple  of  1.4°. 
The  RAM  card  contains  separate  files  for  pointing 
and  firing  limits,  and  while  the  files  are  generally 
identical,  they  do  not  have  to  be.  The  RAM  system 
also  allows  for  implementation  of  a  less  restrictive 
variant  of  the  base  FCO  design,  effectively  allow¬ 
ing  for  a  “pop-up”  zone.  Presently,  this  feature  is 


used  aboard  certain  amphibious  ships  to  reflect  the 
presence  or  absence  of  parked  helicopters.  A  RAM 
P&FCO  circuit  board  is  shown  in  Figure  10,  and  a 
typical  RAM  P&FCO  zone  is  shown  in  Figure  11. 

The  5-inch/62-caliber  gun  also  implements 
P&FCO  zones  with  a  programmed  circuit  board. 
However,  in  this  case,  the  table  consists  of  over 
8,000  values,  meaning  that  the  zone  designer  has 
basically  no  limitation  as  to  the  zone  value  to  be 
implemented.  FCO  design  limitation  comes  from 
the  fact  that  only  30  corners  can  be  specified  in 
the  zone.  The  pointing  zone  for  5-inch/62  guns 
aboard  DDGs  still  consists  of  a  rectangle,  but  the 
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Figure  10.  RAM  P&FCO  Card 


Figure  11.  Typical  RAM  P&FCO  Zone 


gun  variant  being  back-fitted  on  CGs  will  allow 
a  contoured  pointing  zone  to  be  implemented.  A 
5-inch/62  gun  FCO  computer  chip  is  shown  in 
Figure  12,  and  a  typical  5-inch/62  gun  FCO  zone 
is  shown  in  Figure  13. 

One  issue  that  does  not  exist  with  mechani¬ 
cal  systems  is  obsolescence.  As  long  as  drawings 
of  the  part  to  be  replaced  are  available,  a  replace¬ 
ment  part  can  be  manufactured— not  so  for  sys¬ 
tems  using  circuit  cards.  For  instance,  the  chips 
needed  for  NSSMS  boards  are  becoming  increas¬ 
ingly  difficult  to  find.  The  logical  progression  is 
to  bypass  the  need  for  an  externally  programmed 


circuit  board  and  to  upload  the  necessary  files  di¬ 
rectly  into  the  system.  The  first  system  to  go  this 
route  was  the  Mk  46  30mm  gun  aboard  the  LPD 
17  class.  Unfortunately,  the  decision  was  made  to 
incorporate  the  cutout  information  in  the  com¬ 
piled  portion  of  the  gun  control  system  (GCS) 
software.  The  effective  result  is  that  if  cutouts 
need  to  be  revised  due  to  topside  changes,  the  en¬ 
tire  GCS  software  package  needs  to  be  certified 
and  approved  by  the  Weapon  System  Explosives 
Safety  Review  Board  (WSESRB),  adding  consid¬ 
erable  cost  to  the  program.  Ideally,  the  same  soft¬ 
ware  load  would  then  be  applied  to  all  the  guns 
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Figure  12.  Computer  Chip  for  Implementing  5-inch/62  Gun  FCO  Zone 
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across  the  ship  class,  but  this  goal  conflicts  with 
the  staggered  implementation  of  topside  chang¬ 
es.  Experience  shows  that  FCO  design  needs  to  be 
hull- specific.  Indications  are  that  software  chang¬ 
es  are  being  contemplated  that  would  keep  FCO 
zone  information  separate  from  the  compiled 
portion  of  the  GCS  software.  A  typical  Mk  46  Gun 
FCO  zone  is  shown  in  Figure  14. 

An  example  of  a  more  flexible  approach  is 
provided  by  the  Mk  110  57mm  gun,  found  on 
the  Littoral  Combat  Ship  (LCS)-class  ships  and 
the  WMSL  750-class  Coast  Guard  cutter.  The 
P&FCO  zone  information  for  this  gun  is  upload¬ 
ed  as  adaptation  data  to  the  GCS  using  a  ded¬ 
icated  laptop  and  connector.  The  P&FCO  zone 
contour  can  have  elevation  steps  as  small  as  0.5° 


and  as  many  as  100  corners.  Pointing  and  fir¬ 
ing  contours  can  be  independent  of  each  other. 
While  one  may  quibble  over  the  necessity  of  an 
actual  laptop  to  perform  this  information  trans¬ 
fer,  this  basic  approach  seems  to  be  the  way  of  the 
future.  A  typical  Mk  110  gun  FCO  zone  is  shown 
in  Figure  15. 

As  can  be  seen,  P&FCO  zones  can  be  imple¬ 
mented  in  numerous  ways,  and  each  approach 
has  positive  and  negative  characteristics.  Ideally, 
as  new  methods  are  investigated,  the  robustness 
of  the  system,  flexibility  of  zone  design,  and  ease 
of  zone  revision  will  all  be  considered.  NSWCDD 
will  continue  to  work  within  the  constraints  of 
each  P&FCO  system  to  give  our  ships  as  much 
protection  as  possible. 


Figure  14.  Typical  MK  46  Gun  FCO  Zone 


Figure  15.  Typical  MK  110  Gun  FCO  Zone 
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Rapid  integration  projects  are  capability  demonstration  efforts  that  take  existing, 
fielded  technologies  or  mature  developmental  technologies  and  integrate  them  onto  ve¬ 
hicles  to  create  a  system  of  systems.  Current  projects  include  Gunslinger,  the  Full  Spec¬ 
trum  Effects  Platform  (FSEP),  and  Wolfpack.  These  projects  have  focused  on  integrating 
technologies  onto  military  ground  vehicles  to  provide  the  warfighter  with  better  situa¬ 
tional  awareness,  communications,  and  cooperative  engagement  capabilities.  As  their 
name  implies,  these  are  fast-paced  programs,  typically  lasting  12-24  months. 

These  programs  offer  many  challenges  from  a  safety  perspective.  They  are  fast  mov¬ 
ing  and  do  not  follow  the  typical  acquisition  cycle.  Formal  requirements  documents 
may  not  exist.  Any  requirements  are  typically  in  the  form  of  desired  capabilities,  and 
these  tend  to  be  very  high  level.  Schedule  and  budget  constraints  also  limit  the  amount 
and  types  of  testing  that  can  be  performed.  Yet  the  program  goals  require  that  a  system 
safety  program  be  performed  that  will  enable  uniformed  personnel  to  utilize  the  sys¬ 
tem  in  a  warfighter  assessment,  as  well  as  possible  deployment.  This  article  examines  the 
unique  challenges  of  these  projects  and  strategies  for  meeting  them. 

Since  2004,  the  Platform  Integration  Division  at  the  Naval  Surface  Warfare  Cen¬ 
ter  in  Dahlgren,  Virginia,  has  been  engaged  in  rapid  integration  projects.  As  previously 
stated,  these  projects  take  existing,  fielded  technologies  or  mature  developmental  tech¬ 
nologies  (Technology  Readiness  Level  (TRL)  6  and  above),  install  them  onto  military 
vehicles,  and  create  the  software  that  enables  the  systems  to  work  together,  thus  creat¬ 
ing  a  system  of  systems.  In  order  to  ensure  that  the  systems  being  developed  are  useful 
and  effective,  uniformed  personnel  are  brought  in  as  early  in  the  development  process 
as  possible.  Such  involvement  can  range  from  evaluation  of  the  functionality  and  layout 
of  the  graphical  user  interface  to  using  the  vehicle(s)  in  a  training  exercise.  The  ultimate 
evaluation  is  an  operational  evaluation  via  actual  deployment  to  theater. 

The  first  such  project  undertaken  by  the  Division  is  Gunslinger.  Gunslinger  focused 
on  developing  a  multispectral,  on-the-move  hostile  fire  detection  and  counterfire  sys¬ 
tem  that  provides  mobile  ground  forces  in  operational  environments  with  real  time 
and  precise  location  of  hostile  direct  fire,  as  well  as  the  ability  to  engage  the  source  of 
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the  hostile  fire  in  near  real  time.  The  primary  com¬ 
ponents  of  the  system  include  an  electro -optical 
infrared  shot  detection  system,  an  acoustic  shot 
detection  system,  a  stabilized  gun  mount,  and  a  sit¬ 
uational  awareness  (SA)  video  system.  These  sen¬ 
sors  and  weapon  system  have  also  been  integrated 
with  navigation  and  communication  systems  to 
track  event  detections  while  “on-the-move”  and  to 
relay  information  about  those  events  using  either 
satellite  or  wireless  local  area  network  (WLAN) 
communications.  Gunslinger  was  integrated  onto 
a  High  Mobility  Multipurpose  Wheeled  Vehi¬ 
cle  (HMMWV)  and  an  International  Military  Ex¬ 
treme  Truck  -  Military  Version  (MXT-MV),  as 
shown  in  Figure  1. 

Managed  by  the  Office  of  Naval  Research 
(ONR),  Code  30,  Maneuver  Thrust  Area,  Gun¬ 
slinger  is  a  joint  project  among  the  Army,  Navy,  and 
United  States  Marine  Corps  (USMC),  along  with 
several  government  laboratories  and  industry  part¬ 
ners.  Gunslinger  has  recently  completed  a  6-month 
tour  in  Iraq,  where  it  participated  in  over  100  mis¬ 
sions  and  was  used  to  provide  overwatch  surveil¬ 
lance  at  A1  Asad  and  street  patrols  in  Fallujah. 

The  second  rapid  integration  project  undertak¬ 
en  is  the  FSEP,  which  was  initiated  in  response  to  a 
time-critical  Joint  Urgent  Operational  Needs  State¬ 
ment  (JUONS).  The  JUONS  called  for  a  progres¬ 
sive  escalation  of  force  capability  in  order  to  engage 


neutral  and  hostile  crowds  using  nonlethal,  scal¬ 
able  effects  and  solutions  to  overcome  technology 
gaps  to  counter  the  threats  of  rocket-propelled  gre¬ 
nades  (RPG),  improvised  explosive  devices  (IED), 
and  snipers.  The  base  vehicle  for  the  FSEP  efforts 
is  a  Stryker  Infantry  Carrier  Vehicle  (ICV),  shown 
in  Figure  2. 

FSEP  takes  the  Gunslinger  capability  (minus 
the  electro-optical  infrared  shot  detection  system) 
and  combines  it  with  a  suite  of  nonlethal  technol¬ 
ogies— including  a  Long-Range  Acoustic  Device 
(LRAD),  bright  white  lights  (BWL),  and  a  Green 
Beam  Designator  (GBD)  IIIC  laser— to  provide  an 
escalation  of  force  capability.  Three  Stryker  ICVs 
were  equipped  with  the  Spiral  1  FSEP  technology 
and  deployed  to  Iraq  for  operational  evaluation  for 
over  18  months.  While  two  of  the  vehicles  are  still 
in  theater,  the  third  was  hit  by  an  IED  and  was  re¬ 
turned  to  the  United  States  for  repair.  That  vehicle 
was  then  used  for  development  of  Spiral  2,  which 
adds  nonlethal  shove  capability  in  the  form  of  a 
12-GA  shotgun  using  nonlethal  rounds  (sting  balls 
and  rubber  buckshot)  and  66mm  grenade  launcher 
(firing  smoke  and  nonlethal  grenades). 

There  have  been  many  funding  sources  for 
FSEP.  Initiated  by  the  Office  of  the  Secretary  of  De¬ 
fense  (OSD)  and  originally  funded  by  the  Office  of 
Force  Transformation,  FSEP  was  later  transferred 
to  the  Joint  Rapid  Action  Cell  (JRAC).  Current 
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Figure  1.  Gunslinger  Spiral  2  (MXT-MV) 


Figure  2.  FSEP  Spiral  3  (Stryker) 
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sponsors  are  the  Army  Training  and  Doctrine 
Command  (TRADOC),  the  Army  Capabilities  In¬ 
tegration  Center  (ARCIC),  and  the  OSD.  The  pro¬ 
gram  is  managed  by  the  Army  Project  Manager  for 
Close  Combat  Systems  (PM  CCS)  with  the  Proj¬ 
ect  Manager,  Stryker  Brigade  Combat  Team  (PM 
SBCT).  The  Joint  Product  Manager  for  Reconnais¬ 
sance  and  Platform  Integration  (JPM-RPI)  at  the 
U.S.  Army  Edgewood  Chemical  Biological  Center 
(ECBC)  funded  the  development  and  manufacture 
of  the  66mm  articulating  grenade  launcher  sys¬ 
tems  installed  on  the  remote  weapon  system. 

The  final  rapid  integration  project  for  discus¬ 
sion  herein  is  known  as  Wolfpack,  shown  in  Figures 
3  through  5.  Wolfpack  builds  upon  the  capabili¬ 
ties  and  technology  of  FSEP  and  adds  communica¬ 
tions  capability,  enabling  cooperative  engagement 
and  shared  situational  awareness  between  vehicles 
and  between  dismounts  and  vehicles.  Wolfpack 
equipped  three  vehicles: 

•  A  Cougar  Mine  Resistant  Assault  Protected 
(MRAP)  4x4 


•  An  International  MXT-MV 

•  An  Oshkosh  Medium  Tactical  Vehicle  Re¬ 
placement  (MTVR) 

Wolfpack  is  sponsored  by  the  Office  of  the  Un¬ 
der  Secretary  of  Defense  (OUSD),  Acquisition, 
Technology,  and  Logistics  (AT&L)  Rapid  Reaction 
Technology  Office  (RRTO). 

The  Platform  System  Safety  Branch  of  the  Na¬ 
val  Surface  Warfare  Center  Dahlgren,  Virginia, 
performs  system  safety  for  all  three  of  these  proj¬ 
ects.  Gunslinger  and  Wolfpack  are  both  USMC 
projects  and  follow  the  Navys  system  safety  pro¬ 
cesses.  FSEP  is  an  Army  project,  and  system  safety 
testing  for  safety  confirmation  is  performed  by  the 
Aberdeen  Test  Center  (ATC)  in  Maryland. 

Gunslinger  laid  the  groundwork  for  system 
safety  for  rapid  integration  projects.  Their  primary 
sponsor,  ONR,  worked  with  the  Dahlgren  Princi¬ 
pal  for  Safety  (PFS)  and  the  Navy’s  Weapon  System 
Explosives  Safety  Review  Board  (WSESRB)  to  cre¬ 
ate  a  System  Safety  Management  Plan  for  Science 
and  Technology  (S&T)  programs.  Gunslinger  was 


Figure  3.  Wolfpack  Spiral  1  (Cougar) 
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Figure  4.  Wolfpack  Spiral  1  (MXT-MV) 


Figure  5.  Wolfpack  Spiral  1  (MTVR) 
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revolutionary,  in  that  it  was  the  first  time  an  S&T 
program  fully  embraced  a  formal  system  safety  pro¬ 
gram. 

Table  6  of  Appendix  A  of  MIL-STD-882C  pro¬ 
vides  guidance  for  system  safety  activities  based 
upon  level  of  risk  or  dollar  amount.  Small-dollar  or 
low-risk  programs  perform  the  fewest  safety  tasks, 
while  high-risk  or  high-dollar  programs  perform 
the  most  safety  tasks.  The  following  tasks  from  Ta¬ 
ble  6  were  identified  as  being  appropriate  to  the 
program  goals  of  deployment  for  operational  eval¬ 
uation,  while  still  meeting  the  budget  and  schedule 
constraints  of  a  rapid  integration  prototype  effort: 

•  Task  101:  System  Safety  Program 

•  Task  102:  System  Safety  Program  Plan  (SSPP) 

•  Task  106:  Hazard  Tracking 

•  Task  201:  Preliminary  Hazard  List  (PHL) 

•  Task  202:  Preliminary  Hazard  Analysis  (PHA) 

•  Task  204:  Subsystem  Hazard  Analysis  (SSHA) 

•  Task  205:  System  Hazard  Analysis  (SHA) 

•  Task  206:  Operating  and  Support  Hazard 
Analysis  (O&SHA) 

•  Task  207:  Health  Hazard  Assessment  (HHA) 

•  Task  301:  Safety  Assessment 

Tasks  101,  102,  201,  202,  205,  and  301  are  safe¬ 
ty  activities  identified  by  MIL-STD-882C  as  being 
appropriate  for  a  low-risk  or  small-dollar  program. 
Tasks  106,  204,  206,  and  207  are  4  of  the  12  safety 
activities  identified  as  being  appropriate  for  aver¬ 
age  risk  or  medium  dollar  programs.  By  contrast, 
a  high-risk  or  large-dollar  program  has  18  recom¬ 
mended  safety  activities. 

Because  the  goal  of  the  program  was  to  deploy 
a  system  to  Operation  Iraqi  Freedom  for  operation¬ 
al  evaluation,  the  program  had  to  go  before  the  WS- 
ESRB.  Even  though  the  end-user  for  Gunslinger  is 
the  USMC,  the  sponsor  is  the  Navy;  therefore,  two 
separate  risk  acceptance  authorities  were  identified. 
For  the  Navy,  the  risk  acceptance  authorities  were: 

•  Maneuver  Thrust  Manager,  ONR  Code  30 
(low  risks) 

•  Director  of  Applications,  ONR  Code  30  (me¬ 
dium  and  serious  risks) 

•  Deputy  CNR,  ONR  Code  30  (high  risks) 

For  the  USMC,  the  risk  acceptance  authorities  were: 

•  Commanding  Officer,  MWS-373  (low  and 
medium  risks) 

•  Commanding  Officer,  MWSG-37  (serious 
risks) 

•  Commanding  General,  3rd  MAW  (high 
risks) 

All  of  the  residual  risks  for  the  Gunslinger  Spi¬ 
ral  2  Program  were  low  or  medium,  except  for  one 


serious  risk  related  to  the  Mk  45  gun  mount  that 
was  previously  accepted  at  the  appropriate  level 
for  the  High  Speed  Vessel  application.  Prior  to  de¬ 
ployment,  Marines  from  the  Marine  Wing  Support 
Squadron  (MWSS)  373  utilized  the  Gunslinger 
system  in  an  exercise  at  the  Marine  Corps  Ground 
Air  Combat  Center  (MCGACC)  at  29  Palms,  Cal¬ 
ifornia.  The  result  of  this  exercise  was  a  Safe  and 
Ready  report.  After  this  event,  there  was  a  change 
in  deployment  plans,  and  Marines  from  MWSS 
371  utilized  the  Gunslinger  system  in  Desert  Tal¬ 
on  at  Yuma,  Arizona.  Desert  Talon  is  a  predeploy¬ 
ment  exercise. 

As  an  Army  project,  FSEP  follows  a  different 
path  than  Gunslinger.  The  Dahlgren  PFS  performs 
the  same  basic  safety  tasks  as  for  Gunslinger,  but  the 
documentation  delivered  to  the  Army  is  condensed 
into  a  Safety  Assessment  Report  and  a  report  of  the 
hazards  from  the  Hazard  Tracking  Database.  Once 
these  documents  and  the  vehicle(s)  have  been  de¬ 
livered  to  Aberdeen,  the  primary  responsibility  for 
the  safety  testing  of  the  vehicle(s),  risk  acceptance, 
and  the  Safety  Confirmation  is  taken  over  by  the 
Army  and  the  test  and  safety  engineers  of  the  Ab¬ 
erdeen  Proving  Ground.  Safety  testing  can  include: 

•  Software  testing 

•  Functional  safety  testing 

•  Electrical  safety 

•  Egress  safety 

•  Vehicle  stability 

•  Hazards  of  electromagnetic  radiation  to  per¬ 
sonnel,  fuel,  or  ordnance,  etc. 

Aberdeen  Proving  Ground  is  responsible  for 
issuing  the  Safety  Confirmation.  It  should  be  not¬ 
ed,  however,  that  even  though  the  Army  provides 
the  Safety  Confirmation  and  performs  the  official 
safety  testing,  the  safety  work  performed  by  the 
Dahlgren  PFS  was  done  according  to  the  standards 
and  expectations  of  the  WSESRB. 

Spiral  0  of  FSEP  went  through  safety  testing  at 
ATC  to  obtain  a  safety  release  for  Limited  Utility 
Assessment  (LUA)  at  Fort  Benning,  Georgia.  The 
LUA  was  completed,  and  feedback  was  incorporat¬ 
ed  into  FSEP  Spiral  1.  FSEP  Spiral  1  went  through 
safety  testing  at  ATC  to  obtain  a  Safety  Confirma¬ 
tion  for  deployment  to  Operation  Iraqi  Freedom. 
FSEP  Spiral  2  is  currently  undergoing  safety  testing 
at  ATC  to  obtain  a  Safety  Confirmation  for  deploy¬ 
ment  to  Operation  Iraqi  Freedom. 

As  a  USMC  project,  Wolfpack  follows  in  Gun¬ 
slingers  footsteps,  with  Dahlgren  responsible 
for  the  system  safety  program.  There  is,  howev¬ 
er,  one  significant  difference  between  Gunslinger 
and  Project  Wolfpack.  In  Project  Wolfpack,  exper¬ 
imentation  exercises  with  Marines  were  planned 
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as  part  of  the  development  effort.  When  the  proj¬ 
ect  began  in  February  2007,  an  introductory  meet¬ 
ing  was  held  with  the  WSESRB  Chair  and  the 
Marine  Corps  Systems  Command  (MCSC)  Safe¬ 
ty  Director.  During  that  meeting,  it  was  suggest¬ 
ed  that  the  Wolfpack  sponsor  put  a  memorandum 
of  agreement  (MOA)  in  place  with  the  Safety  Of¬ 
fice  of  MCSC,  designating  MCSC  the  authority  to 
provide  safety  releases  for  the  experimentation  ex¬ 
ercises.  This  effort  was  initiated,  and  the  MOA  was 
signed  among  the  OUSD,  the  AT&L  Director,  the 
RRTO,  and  the  Commander,  MCSC. 

The  safety  data  sent  to  MCSC  for  review  con¬ 
sisted  of  a  Safety  Assessment  Report  that  combined 
the  results  of  the  various  safety  analyses  and  a  copy 
of  the  Hazard  Tracking  Database.  Additional  docu¬ 
mentation  included  safety  information  on  existing 
systems,  test  reports  from  effects  of  electromagnet¬ 
ic  energy  testing  (performed  by  the  Electromag¬ 
netic  and  Sensor  Systems  Department,  Advanced 
Science  and  Technology  Branch  at  Dahlgren),  and 
vehicle  stability  test  reports  from  the  National  Au¬ 
tomotive  Test  Center  (NATC)  in  Nevada.  The  risk 
acceptance  authority  for  all  risks  was  the  com¬ 
manding  officer  of  the  unit  participating  in  the 


experimentation  exercise  and  the  project  sponsor. 
The  Safety  Assessment  Report  was  also  submit¬ 
ted  to  the  risk  acceptance  authorities  along  with  a 
risk  acceptance  document  summarizing  the  resid¬ 
ual  risks.  The  risk  acceptance  document  was  then 
signed  by  the  risk  acceptance  authorities  and  sub¬ 
mitted  as  part  of  the  safety  package  that  was  pre¬ 
pared  for  review  by  MCSC. 

To  date,  Project  Wolfpack  has  held  three  exper¬ 
imentation  exercises.  The  MCSC  Safety  Director 
provided  a  limited  safety  release  for  each  of  these 
events.  The  first  took  place  in  August  2007  at  a  live 
fire  range  at  the  Marine  Corps  Base  in  Quantico, 
Virginia;  the  second  and  third  exercises  took  place 
in  February  and  August  2008  at  MCGACC  at  29 
Palms,  California.  The  first  two  safety  releases  came 
directly  from  MCSC;  but  when  it  was  time  to  ob¬ 
tain  the  third  safety  release,  the  new  safety  director 
required  the  safety  case  for  Project  Wolfpack  to  be 
reviewed  by  the  Laser  Safety  Review  Board  (LSRB), 
the  WSESRB,  and  the  Software  System  Safety  Tech¬ 
nical  Review  Panel  (SSSTRP).  Thanks  to  the  coop¬ 
eration  of  all  three  boards,  the  tight  schedule  of  the 
project  was  accommodated,  and  a  safety  release  for 
the  August  2008  event  was  obtained. 
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These  three  projects  are  revolutionary  in  sever¬ 
al  ways.  First,  they  set  a  precedent  by  incorporating 
a  formal  system  safety  program  into  an  S&T  rapid 
integration  effort.  System  safety  was  integrated  into 
these  efforts  from  their  initiation.  Next,  ONRs  in¬ 
vestment  of  time  and  money  into  the  development 
of  a  System  Safety  Management  Plan  for  S&T  pro¬ 
grams  was  particularly  crucial.  Without  the  system 
safety  success  of  Gunslinger,  FSEP  and  Wolfpack 
would  have  had  a  far  more  difficult  way  forward. 
FSEP  laid  the  groundwork  for  collaboration  be¬ 
tween  the  Army  and  the  Navy  with  regard  to  sys¬ 
tem  safety  and  has  created  a  positive  system  safety 
relationship  between  Dahlgren  and  Aberdeen. 
Project  Wolfpack  has  established  a  mechanism  for 
obtaining  safety  releases  for  USMC  participation 
in  experimentation  exercises. 

These  efforts  set  another  precedent  by  involving 
the  end-user  in  the  development  effort  as  early  as 
possible.  This  approach  of  prototyping,  combined 
with  experimentation  exercises,  provides  a  model 
for  acquisition  as  new  technologies  can  be  exercised 
and  vetted  with  the  end-user,  resulting  in  better  re¬ 
quirements  for  formal  acquisition  programs.  In  ad¬ 
dition,  by  involving  the  user  in  the  development 


effort,  especially  with  regard  to  hardware  and  soft¬ 
ware  user  interfaces,  these  projects  are  taking  a 
more  human-centered  approach  to  system  design. 
A  human-centered  design  approach  results  in  inter¬ 
faces  that  are  more  intuitive  and  easier  to  use,  which 
reduces  the  risk  of  operator  error  and  increases  the 
overall  awareness  of  the  state  of  the  system. 

As  these  projects  transition  to  programs  of  re¬ 
cord,  the  system  safety  work  that  has  already  been 
performed  reinforces  the  value  and  necessity  of 
early  integration  of  system  safety  into  the  over¬ 
all  development  effort.  The  cross-service  nature  of 
these  projects  also  helps  to  reinforce  the  joint  sys¬ 
tem  safety  process  that  is  currently  being  estab¬ 
lished. 
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NSWCDD’s  Role  as  the  Lead  Navy  Technical 
Laboratory  (LNTL)  for  Laser  Safety  Within 
the  Department  of  the  Navy  (DON) 


By  Sheldon  Zimmerman ,  Robert  Aldrich and  Thomas  Fraser 


Since  the  1960s,  various  military  organizations  have  provided  Laser  Radiation 
Health  Standards  criteria  and  established  medical  surveillance  programs.  However,  pri¬ 
or  to  1979  no  lead  agency  existed  to  ensure  uniform  application  of  these  criteria  to  mil¬ 
itary  systems.  Laser  health  hazards  prevention  was  left  almost  entirely  to  the  individual 
system  developers  and  users. 

In  March  1979,  the  Chief  of  Naval  Materiel  designated  the  Naval  Electronic  Sys¬ 
tems  Command  (now  designated  as  the  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR))  as  its  lead  agency  for  the  Navy  Laser  Hazards  Prevention  Program.  SPAWAR 
surrendered  its  role  as  the  central  point  of  contact  for  Laser  Safety  in  the  mid-1990s. 

Since  then,  the  Secretary  of  the  Navy  through  SECNAVINST  5100.14,  Military 
Exempt  Lasers ,  series  has  designated  the  Bureau  of  Medicine  and  Surgery  (BUMED)  as 
the  Administrative  Lead  Agency  (ALA)  and  the  Naval  Sea  Systems  Command  (NAVSEA) 
as  the  Technical  Lead  Agent  (TLA)  for  the  Navy  and  Marine  Corps.  Subsequently, 
OPNAVINST  5100.27B/MCO  5 104. 1C,  Navy  Laser  Hazards  Control  Program,  describes 
the  entire  program  in  its  current  state. 

Department  of  the  Navy  (DON)  policy  is  to  identify  and  control  laser  radiation  haz¬ 
ards  early  during  design  and  development  as  a  matter  of  military  necessity.  It  is  also  the 
policy  of  the  DON  to  ensure  that  personnel  are  not  exposed  to  laser  radiation  in  excess 
of  the  Maximum  Permissible  Exposure  (MPE)  limit  throughout  the  life  cycle  of  a  laser 
system,  which  includes: 

•  Research  •  Design  •  Testing  •  Development 

•  Evaluation  •  Acquisition  •  Deployment  •  Operation 

•  Support  •  Maintenance  •  Demilitarization  •  Disposal 

By  mandate,  policy,  and  principle,  the  DON  provides  personnel  safety  oversight 
for  the  use  of  all  military  lasers  in  its  inventory.  The  heart  of  this  oversight  is  realized 
by  a  required  safety  review  conducted  by  the  Navy  Laser  Safety  Review  Board  (LSRB). 
The  LSRB  comprises  representatives  from  all  the  System  Commands,  the  Naval  Safety 
Center,  Marine  Corps  Headquarters,  BUMED,  and  the  Lead  Navy  Technical  Laborato¬ 
ry  (LNTL)  for  Navy  and  Marine  Corps  Laser  Safety. 
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The  Naval  Surface  Warfare  Center,  Dahlgren 
Division  (NSWCDD),  Code  G73  has  maintained 
the  technical  lead  for  DON  Laser  Safety  for  al¬ 
most  30  years  and  has  been  designated  by  NAV- 
SEA  as  the  LNTL.  The  LNTL  provides  the  expertise 
required  to  independently  evaluate  and  verify  the 
technical  aspects  of  safety-related  design  and  ap¬ 
plication  criteria  for  lasers  and  laser  systems  within 
both  the  inventory  and  acquisition  processes  of  the 
DON,  including  those  used  for  joint  service  and 
interagency  applications  and  missions.  The  joint 
laser  safety  review  process  is  shown  in  Figure  1. 

To  this  specialized  expertise,  the  LNTL  at 
NSWCDD  maintains  a  group  of  laser  safety  special¬ 
ists  holding  leadership  positions  on  government, 
national,  and  international  laser  safety  standards 
committees.  For  example,  members  of  the  LNTL 
hold  chairmanships  on  the  American  National 
Standards  Institute  (ANSI)  Committee  for  the  Safe 
Use  of  Lasers  Outdoors,  and  the  ANSI  and  Inter¬ 
national  Electrotechnical  Commission  groups  on 


Laser  Safety  Measurements.  The  LNTL  performs 
advanced  laser  parameter  verification  measure¬ 
ments  and  determines  applicable  laser  safety  rec¬ 
ommendations  as  the  technical  evaluators  for  the 
LSRB.  These  measurements  are  performed  either 
in  the  local  laser  safety  laboratory  maintained  at 
Dahlgren  or  at  other  government  or  manufacturer 
facilities  using  National  Institute  of  Standards  and 
Technology  (NIST)  traceable  measurement  equip¬ 
ment.  An  example  laser  system  under  evaluation  is 
shown  in  Figure  2. 

One  of  the  primary  roles  the  LNTL  fills  is  pro¬ 
viding  technical  support  to  the  Navy  in  utilizing 
existing  and  emerging  laser  technology  in  the  de¬ 
velopment  of  weapons  and  weapon-related  sys¬ 
tems.  For  example,  Navy  maritime  forces  and  the 
Marine  Corps  recently  identified  a  capability  gap 
in  their  operations,  which  they  intended  to  fill 
through  the  use  of  a  dazzling  laser  system  for  the 
purpose  of  hailing  and  warning  suspected  threats. 
After  an  analysis  of  alternatives  and  execution  of 
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COTS  =  Commercial  Off-the-Shelf 

L/ORP  =  Laser/Optical  Radiation  Program  (Army) 

LSLSRC  =  Lead  Service  Laser  Safety  Review  Coordinator 
LSSRB  =  Laser  System  Safety  Review  Board 
NDI  =  Nondevelopmental  Item 
SLSRA  =  Service  Laser  Safety  Review  Authority;  i.e.,  Chair 
Navy  LSRB;  Chair,  Air  Force  LSSRB; 
and  Manager,  L/ORP 
SSL  =  System  Safety  Lead 
SSRC  =  Service  Safety  Review  Coordinator 


Figure  1.  Joint  Laser  System  Safety  Review  Process 
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Figure  2.  Ghost  Laser  System  Under  Evaluation 


a  source- selection  process,  a  device  was  select¬ 
ed,  and  a  preproduction  unit  was  submitted  to  the 
LNTL  and  LSRB  for  review  and  approval  for  use. 
The  original  preproduction  Green  Beam  Designa¬ 
tor-Ill  Custom  (GBD-IIIC)  system,  shown  in  Fig¬ 
ure  3,  had  a  nominal  hazard  distance  to  the  naked 
eye  of  about  114  m  for  a  10-second  exposure.  The 
refined  production  version  of  the  GBD-IIIC  that 
was  fielded  had  a  nominal  hazard  distance  to  the 
naked  eye  of  only  about  63  m  for  a  10-second  ex¬ 
posure.  Both  of  these  system  options  were  inher¬ 
ently  dangerous,  as  permanent  eye  damage  was 
possible  within  the  hazard  distance  to  those  ex¬ 
posed  to  the  laser  beam.  Acting  on  recommenda¬ 
tions  and  requirements  from  the  LSRB  and  LNTL, 
the  Marine  Corps  undertook  a  system  improve¬ 
ment  effort  to  produce  a  dazzling  laser  system  that 
could  maintain  the  desired  functionality,  while  si¬ 
multaneously  maintaining  a  high  degree  of  safety. 
The  result  of  that  collaborative  effort  was  the  cur¬ 
rent  system  entering  the  fielding  cycle,  which  is 
known  as  the  LA-9/Portable,  or  LA-9/R  The  LA- 
9/P  uses  a  Class  1  laser  rangefinder  retrofitted  to 
the  GBD-IIIC  to  determine  the  distance  between 
the  laser  and  the  target,  and  implements  a  Safety 


Control  Module  (SCM)  that  switches  off  the  dan¬ 
gerous  beam  if  the  target  is  within  the  hazard  dis¬ 
tance  of  the  laser.  This  design  virtually  eliminates 
the  possibility  of  a  laser  injury.  While  currently  an 
interim  solution,  it  is  nonetheless  one  that  moves 
the  program  down  the  road  toward  creating  an  in¬ 
herently  safe  dazzling  laser. 

In  addition  to  providing  laser-related  engi¬ 
neering  support  to  programs,  the  LNTL  team  also 
provides  advanced  laser  safety  training  to  Navy  and 
Marine  Corps  personnel.  Two  of  the  four  DON  la¬ 
ser  safety  certifications  are  provided  by  this  group 
through  the  courses  taught  at  NSWCDD,  which 
include  the  Technical  Laser  Safety  Officer  (TLSO) 
and  Laser  Safety  Specialist  (LSS)  classes.  Achieving 
TLSO  certification  qualifies  the  certificate  holder 
to  be  designated  as  a  command  Laser  System  Safe¬ 
ty  Officer  in  order  to  run  a  base  or  facility-level  la¬ 
ser  hazard  control  program,  or  to  be  a  Range  Laser 
Safety  Officer.  LSS  certification  equips  the  course 
graduate  with  the  knowledge  to  perform  a  laser 
hazard  evaluation.  At  the  request  of  PMS  480,  the 
LNTL  conducted  the  TLSO  course  at  NSWCDD 
(see  Figure  4)  during  the  LA-9/P  development  ef¬ 
fort,  in  support  of  fielding  the  LA- 9/P  green  laser 


126 


Naval  Sea  Systems  Command 


NSWCDD’s  Role  as  the  Lead  Navy  Technical 
Laboratory  (LNTL)  for  Laser  Safety  Within 
the  Department  of  the  Navy  (DON) 


Figure  3.  GBD-IIIC  Dazzling  Laser  System  Under  Evaluation 


Figure  4.  Navy  uniformed  members  and  civilian  workforce  members  sitting  for  the  TLSO  examination 
in  the  lobby  conference  room  of  building  1470 
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devices  to  Navy  Maritime  forces.  Immediately  fol¬ 
lowing  the  TLSO  exam  for  that  class,  the  students 
were  given  a  demonstration  and  hands-on  intro¬ 
duction  to  the  LA-9/P  on  the  abandoned  airstrip 
(see  Figures  5  and  6). 

The  basic  philosophy  of  the  LNTL  is,  whenev¬ 
er  possible,  ££do  what  makes  sense”  with  regard  to  la¬ 
ser  safety  Strict,  but  necessary,  laser  regulations  add 


both  structure  and  rigor  to  the  task,  but  a  reasonable 
approach  to  merging  the  regulations  with  the  com¬ 
plex  principles  of  laser  system  safety  typically  gener¬ 
ates  satisfactory  results.  Aiding  users,  operators,  and 
laser  safety  officers  in  understanding  why  a  require¬ 
ment  exists  is  generally  helpful  in  ensuring  that  they 
adhere  to  it,  and  adopting  a  common  sense  attitude 
toward  laser  safety  facilitates  this. 


Figure  5.  Navy  uniformed  members  and  civilian  workforce  members  receiving  a  demonstration  of  the 
LA  9/P  mounted  on  a  modified  “rifle”  stock  from  the  device  manufacturer 
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Figure  6.  Navy  uniformed  members  and  civilian  workforce  members  conducting  a  hands-on  introduc¬ 
tion  to  the  LA  9/P  mounted  on  a  modified  “rifle”  stock 
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“ Our  men  and  women  in  uniform  are  putting  their  lives  on 
the  line  every  day  in  defense  of  our  freedoms  and  way  of  life. 
Hence,  we  all  have  an  inescapable  duty  and  responsibility  to 
equip  them  with  the  absolutely  best  capabilities  possible, 
with  safety  as  a  primary  and  enduring  factor.  System  safety 
is  not  nice  to  have;  it  is  an  integral  and  essential  part  of  the 
systems  engineering  process.” 

Mr.  Tom  Rollow 

Deputy  Assistant  Secretary  of  the  Navy  (Safety) 
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